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Abstract 


The  task  of  checking  if  a  computer  system  satisfies  its  timing  specifications  is  extremely 
important.  These  systems  are  often  used  in  critical  applications  where  failure  to  meet  a 
deadline  can  have  serious  or  even  fatal  consequences.  This  work  proposes  an  efficient 
method  for  performing  this  verification  task.  The  method  is  based  on  temporal  logic 
model  checking,  a  technique  for  verifying  concurrent  reactive  systems.  In  the  proposed 
technique,  a  real-time  system  is  modeled  by  a  state-transition  graph  represented  by  binary 
decision  diagrams.  Efficient  symbolic  algorithms  exhaustively  explore  the  state  space  to 
determine  whether  the  system  satisfies  a  given  specification. 

In  addition  to  accepting  an  explicit  timing  constraint,  and  checking  if  it  is  satisfied,  our 
approach  computes  quantitative  timing  information  such  as  minimum  and  maximum  time 
delays  between  given  events.  These  results  provide  insight  into  the  behavior  of  the  system 
as  well  as  assist  in  the  determination  of  its  temporal  correctness.  The  technique  evaluates 
how  well  the  system  works  or  how  seriously  it  fails,  as  opposed  to  only  if  it  works  or  not, 
allowing  a  much  richer  analysis  than  previous  methods.  Response  time  to  events,  schedu- 
lability  of  a  task  set  and  system  performance  are  examples  of  information  produced  by  our 
algorithms.  They  also  provide  insight  into  how  changes  in  the  parameters  affect  global 
behavior  and  allow  fine-tuning  of  the  system  based  on  these  results. 

These  techniques  have  been  used  in  the  verification  of  several  industrial  real-time  systems 
such  as  an  aircraft  controller,  a  robotics  system  and  the  PCI  local  bus,  demonstrating  that 
the  method  proposed  is  efficient  enough  to  be  used  in  real-world  designs.  The  examples 
show  how  the  information  produced  can  assist  in  designing  more  efficient  and  reliable 
real-time  systems. 
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“You  must  remember  this, 
a  kiss  is  just  a  kiss, 
A  sigh  is  just  a  sigh; 
The  fundamental  things  apply. 
As  time  goes  by.” 

—  Herman  Hupfeld. 
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A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


Chapter  1  Overview 


1 .1  Motivation 

In  many  computer  applications  predictable  response  times  are  essential  for  the  correctness 
of  the  system.  Such  systems  are  called  real-time  systems.  They  occur  in  many  critical 
applications  in  which  a  late  (or  sometimes  early)  response  can  have  severe  consequences. 
Examples  of  such  applications  include  controllers  for  aircraft,  industrial  machinery  and 
robots.  Due  to  the  nature  of  such  applications,  errors  in  real-time  systems  can  be 
extremely  dangerous,  even  fatal.  Guaranteeing  the  correctness  of  a  complex  real-time  sys¬ 
tem  is  an  important  and  non-trivial  task.  Because  of  this,  only  conservative  and  usually  ad 
hoc  approaches  to  design  and  implementation  are  routinely  used.  This  leads  to  predictable 
but  inefficient  designs.  The  use  of  modem  software  engineering  techniques  can  improve 
the  efficiency  of  these  systems  without  forgoing  predictability.  Recently,  the  development 
of  methods  such  as  the  rate  monotonic  scheduling  theory  [53,59,68]  has  helped  increase 
the  popularity  of  formal  approaches  by  providing  designers  with  powerful  tools  for  ana¬ 
lyzing  real-time  systems.  Current  real-time  designs  incorporate  these  ideas  with  increasing 
frequency. 

Other  factors  make  the  validation  of  real-time  and  non  real-time  systems  particularly  diffi¬ 
cult.  The  architecture  of  computer  applications  is  becoming  more  and  more  complex  each 


A  Quantitative  Approach  to  the  Formai  Verification  of  Real-Time  Systems 


13 


Overview 

day.  The  more  complex  a  system,  the  higher  the  possibility  of  errors  being  introduced  in 
its  design.  Moreover,  performance  is  also  becoming  a  more  important  factor  in  the  success 
of  new  applications.  Due  to  competition,  new  products  have  to  fully  utilize  the  available 
resources.  A  slow  component  can  compromise  the  performance  of  the  whole  system,  and 
consequently  its  acceptance  by  the  market.  Although  not  traditionally  associated  with  real¬ 
time  systems,  verifying  timing  properties  of  these  applications  is  also  critical.  The  task  of 
verifying  that  new  applications  satisfy  their  timing  specifications  is  more  critical  and  diffi¬ 
cult  today  than  ever. 

The  main  objective  of  this  work  is  to  explore  the  application  of  formal  methods  to  the  val¬ 
idation  of  real-time  systems.  Methods  such  as  temporal  logic  model  checking  [10,19,20] 
have  been  very  successful  in  validating  realistic  industrial  designs.  Model  checking  tech¬ 
niques  have  the  ability  to  verify  designs  with  extremely  large  state  spaces  efficiently. 
Models  with  up  to  10^®  states  can  be  verified  in  minutes  [10,15].  Methods  such  as  rate 
monotonic  theory  offer  an  elegant  way  of  analyzing  the  performance  of  a  real-time  sys¬ 
tem.  We  have  developed  a  tool  for  the  analysis  of  real-time  systems  by  combining  ideas 
from  both  techniques.  This  tool  allows  the  user  to  define  a  real-time  system  using  a  lan¬ 
guage  especially  designed  to  simplify  the  description  of  time  related  characteristics.  Algo¬ 
rithms  derived  from  model  checking  are  used  to  extract  quantitative  properties  of  such  a 
model.  This  information  is  used  to  check  if  the  system  does  indeed  satisfy  its  temporal 
specifications.  Moreover,  our  algorithms  provide  an  insight  into  the  behavior  of  the  sys¬ 
tem,  helping  to  understand  and  optimize  its  design.  We  believe  that  the  use  of  formal 
methods  can  increase  the  efficiency  and  reliability  of  systems  in  general,  and  particularly 
of  real-time  systems.  It  is  our  hope  that  this  work  and  its  future  extensions  can  contribute 
to  this  goal  and  open  new  possibilities  in  the  design  of  efficient  and  reliable  real-time  and 
non  real-time  systems. 
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Verification  Tools  for  Real-Time  Systems 

1 .2  Verification  Toois  for  Reai-Time  Systems 

Temporal  Logic  Model  Checking 

Temporal  logic  model  checking  [19,20]  is  an  approach  for  the  verification  of  concurrent 
systems  that  has  achieved  significant  results  recently.  In  this  technique,  computer  systems 
are  represented  by  state-transition  graphs  and  specifications  are  written  as  formulas  in  a 
propositional  temporal  logic.  Verification  is  accomplished  by  an  efficient  search  procedure 
that  views  the  transition  system  as  a  model  for  the  logic,  and  determines  if  the  specifica¬ 
tions  are  satisfied  by  that  model. 

There  are  several  benefits  to  this  approach.  An  important  one  is  that  the  procedure  is  com¬ 
pletely  automatic.  The  model  checker  accepts  a  model  description  and  logic  formulas 
describing  the  specifications;  it  then  determines  if  the  formulas  are  true  or  not  for  that 
model.  If  a  formula  is  not  true,  the  model  checker  can  often  provide  a  counterexample. 
The  counterexample  is  an  execution  trace  that  shows  why  the  formula  is  not  true.  This  is 
an  extremely  useful  feature  because  it  can  help  locate  the  source  of  the  error  and  speed  up 
the  debugging  process.  Another  benefit  is  the  ability  to  verify  partially  specified  systems 
using  nondeterminism.  If  the  behavior  of  the  component  that  determines  the  value  of  a 
given  variable  hasn’t  been  specified,  the  variable  can  be  assigned  any  possible  value  non- 
deterministically.  The  actual  behavior  of  the  variable  is  a  subset  of  the  modelled  behavior, 
and  useful  information  about  correcmess  can  be  gathered  before  all  the  details  have  been 
determined.  This  allows  the  verification  to  proceed  concurrently  with  the  design. 

The  concept  of  symbolic  model  checking  has  been  developed  later  [10,62].  In  this 
approach  the  transition  relation  is  represented  implicitly  by  boolean  formulas,  and  imple¬ 
mented  by  binary  decision  diagrams  [6].  This  usually  results  in  a  much  smaller  represen¬ 
tation  for  the  transition  relation  and  set  of  reachable  states,  allowing  the  size  of  the  models 

being  verified  to  increase  up  to  more  than  10^®  states.  By  using  such  techniques  it  has 
become  possible  to  verify  realistic  industrial  systems  formally.  Significant  results  have 

been  achieved,  such  as  the  verification  of  the  Futurebus'*'  protocol,  adopted  by  the  U.S. 
Navy  [23].  That  work  has  uncovered  protocol  errors  that  were  not  previously  known. 
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It  is  possible  to  use  symbolic  model  checking  to  verify  real-time  systems.  However,  cur¬ 
rent  tools  have  limitations  that  make  it  difficult  to  perform  this  verification.  It  is  difficult, 
for  example,  to  express  timing  properties.  It  is  possible  to  express  the  property  that  “event 
p  will  happen  in  the  future”,  but  it  is  not  simple  to  express  the  property  that  “event  p  will 
happen  in  at  most  n  time  units”.  Moreover,  quantitative  information  such  as  response  time 
or  the  number  of  occurrences  of  events  cannot  be  directly  obtained  using  these  techniques. 
Pure  symbolic  model  checking  cannot  be  used  in  a  natural  and  efficient  way  to  verify 
many  types  of  real-time  systems  that  occur  frequently  in  practice. 

Rate  Monotonic  Scheduling  Theory 

Because  real-time  systems  are  used  in  critical  applications,  until  recently  only  conserva¬ 
tive  approaches  have  been  commonly  used  in  their  design,  leading  to  simple  but  inefficient 
designs.  One  example  of  such  a  safe  technique  is  static  time-slicing,  which  divides  time 
equally  among  all  tasks.  Each  task  executes  until  its  time  slot  has  been  used  and  then 
releases  the  processor.  The  resulting  program  is  very  simple  to  analyze,  but  rather  ineffi¬ 
cient,  since  all  tasks  are  given  equal  resources,  regardless  of  their  importance  or  resource 
utilization.  Recently,  more  powerful  techniques  to  analyze  the  behavior  of  a  real-time  sys¬ 
tem  have  become  more  popular.  The  rate  monotonic  scheduling  theory  (RMS)  [53,59,68] 
is  one  example.  The  RMS  theory  is  applicable  to  systems  described  by  a  set  of  periodic 
tasks.  It  consists  of  two  components,  the  first  being  an  algorithm  for  assigning  priorities  to 
tasks  in  order  to  maintain  predictability.  This  algorithm  assigns  higher  priorities  to  pro¬ 
cesses  with  shorter  periods.  Optimal  response  time  with  respect  to  static  priority  algo¬ 
rithms  is  guaranteed  by  the  RMS  theory  if  priorities  are  assigned  according  to  this  rule 
[59].  The  second  component  of  the  RMS  theory  is  a  schedulability  test  based  on  total  CPU 
utilization;  a  set  of  processes  (which  have  priorities  assigned  according  to  RMS)  is  sched- 
ulable  if  the  total  utilization  is  below  a  computed  threshold.  If  the  utilization  is  above  this 
threshold,  schedulability  is  not  guaranteed.  RMS  is  a  powerful  tool  for  analyzing  real-time 
systems.  It  is  simple  to  use,  yet  it  provides  very  useful  information  for  designers. 

However,  this  analysis  imposes  a  series  of  restrictions  on  the  set  of  processes.  Only  certain 
types  of  processes  are  considered,  with  limitations,  for  example,  on  periodicity  and  syn- 
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chronization.  Recent  work  has  extended  this  theory  to  more  general  classes  of  processes, 
but  limitations  still  exist  [38].  Although  suited  to  the  verification  of  real-time  systems, 
RMS  can  only  handle  systems  that  can  be  described  within  the  theory.  Moreover,  the  types 
of  properties  that  can  be  verified  is  also  restricted  to  properties  that  can  be  modeled  as  task 
execution  times.  Verifying  different  types  of  systems  such  as  distributed  systems  or  sys¬ 
tems  that  do  not  have  a  regular  communication  pattern  is  not  a  trivial  task  in  general.  The 
task  of  checking  for  properties  that  cannot  be  easily  expressed  as  task  execution  times 
such  as  the  number  of  occurrences  of  arbitrary  events  in  the  system  can  also  be  complex. 

Other  Methods 

Another  approach  to  schedulability  analysis  uses  algorithms  for  computing  the  set  of 
reachable  states  of  a  finite-state  system  [18,35,36].  A  model  for  the  real-time  system  is 
constmcted  with  the  added  constraint  that  whenever  an  exception  occurs  (e.g.  a  deadline  is 
missed)  the  system  transitions  to  a  special  exception  state.  Verification  consists  of  com¬ 
puting  the  set  of  reachable  states  and  checking  whether  the  exception  state  is  in  this  set. 
No  restrictions  are  imposed  on  the  model  in  this  approach,  but  the  algorithm  only  checks 
if  exceptions  can  occur  or  not.  Other  types  of  properties  cannot  be  verified,  unless  encoded 
in  the  model  as  exceptions.  Even  though  most  properties  can  be  encoded  as  exceptions, 
this  can  sometimes  be  difficult  and  error-prone.  Symbolic  model  checking  techniques 
have  also  been  extended  to  handle  real-time  systems  [28,29,77].  However,  these  methods 
as  well  as  the  others  mentioned  only  determine  if  the  system  satisfies  a  given  property,  and 
do  not  provide  detailed  information  on  its  behavior.  Restricted  quantitative  analysis  on 
discrete-time  models  can  be  performed  in  [27],  but  only  to  the  extent  of  computing  mini¬ 
mum/maximum  delays. 

In  this  work  we  use  a  discrete  notion  of  time.  In  recent  years,  there  has  been  considerable 
research  on  algorithms  that  use  continuous  time  [1,2,34,39,41,55,63].  Most  of  these  tech¬ 
niques  use  a  transition  relation  with  a  finite  set  of  real-valued  clocks  and  constraints  on 
times  when  transitions  may  occur.  It  can  be  argued  that  such  algorithms  lead  to  more  accu¬ 
rate  results  than  discrete  time  algorithms.  However,  an  uncountable  infinite  state  space  is 
required  to  handle  continuous  time,  because  the  time  component  in  the  states  can  take 
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arbitrary  real  values.  Most  verification  procedures  based  on  this  paradigm  depend  on  con¬ 
structing  a  finite  quotient  space  called  a  region  graph  out  of  the  infinite  state  space.  Unfor¬ 
tunately,  the  region  graph  construction  is  very  expensive  in  practice  and  current 
implementations  of  the  algorithms  can  only  handle  quotient  spaces  with  at  most  a  few 
thousand  states.  This  makes  it  impossible  to  verify  large  complex  systems  such  as  the  ones 
described  in  chapter  6  using  continuous  time  tools.  Dense  time  models  in  which  restricted 
quantitative  analysis  can  be  performed  can  be  found  in  [42,75]. 


1.3  The  Proposed  Approach 

In  this  work  we  propose  a  new  method  for  specifying  and  verifying  real-time  systems.  The 
system  being  verified  is  specified  in  the  Verus  language  and  then  compiled  into  a  state- 
transition  graph.  Algorithms  derived  from  symbolic  model  checking  are  used  to  compute 
quantitative  information  about  the  model.  An  important  benefit  of  this  approach  is  that  the 
Verus  language  has  been  especially  designed  to  allow  a  straightforward  description  of  the 
temporal  characteristics  of  programs.  Another  advantage  is  that  the  information  produced 
allows  the  user  to  check  the  temporal  correctness  of  the  model:  schedulability  of  the  tasks 
of  the  system  can  be  determined  by  computing  their  response  time;  reaction  times  to 
events  and  several  other  parameters  of  the  system  can  also  be  analyzed  by  this  method. 
This  information  provides  insight  into  the  behavior  of  the  system  and  in  many  cases  it  can 
help  identify  inefficiencies  and  suggest  optimizations  to  the  design.  The  same  algorithms 
can  then  be  used  to  analyze  the  performance  of  the  modified  design.  The  evaluation  of 
how  the  optimizations  affect  the  design  can  be  done  before  the  actual  implementation. 
This  can  significantly  reduce  development  costs. 

Other  advantages  of  our  approach  include  the  fact  that  the  Verus  code  serves  as  a  precise 
description  for  the  system,  which  can  uncover  subtle  ambiguities  and  can  be  used  for  doc¬ 
umentation  purposes.  Also,  because  we  use  a  discrete  notion  of  time,  we  are  able  to  take 
advantage  of  symbolic  techniques  in  which  the  transition  relation  is  represented  by  a 
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binary  decision  diagram.  This  enables  us  to  handle  systems  that  are  several  orders  of  mag¬ 
nitude  larger  than  can  be  handled  using  continuous  time  techniques. 

Our  method  extends  several  others  that  have  been  mentioned.  The  model  of  a  real-time 
system,  and  the  algorithms  for  exploring  the  state  space  are  derived  from  model  checking. 
However,  the  method  proposed  allows  the  natural  expression  of  many  types  of  real-time 
properties  that  cannot  be  easily  described  in  the  original  method,  such  as  properties  that 
depend  on  the  exact  timing  behavior  of  the  system.  The  definition  of  real-time  system,  and 
of  its  main  characteristics  are  derived  from  the  rate  monotonic  theory.  But  unlike  RMS, 
our  approach  does  not  impose  a  priori  restrictions  on  the  types  of  systems  and  properties 
being  verified.  Limitations  do  exist,  however,  due  mostly  to  the  complexity  of  the  verifica¬ 
tion  algorithms.  But  they  do  not  depend  on  the  structure  of  the  system,  only  on  the  amount 
of  time  and  memory  required  for  verification. 

An  important  characteristic  of  the  method  proposed  is  that  it  counts  the  number  of  compu¬ 
tation  steps  between  events,  or  the  number  of  occurrences  of  events  in  an  interval.  Because 
of  this  it  finds  application  in  synchronous  systems  in  general,  such  as  computer  circuits 
and  protocols.  Real-time  systems  usually  do  not  execute  in  lock-step,  and  would  not  seem 
to  be  appropriate  for  our  method.  However,  they  are  subject  to  tight  timing  constraints, 
which  are  difficult  to  satisfy  in  an  asynchronous  design.  For  this  reason  real-time  system 
developers  often  significantly  reduce  asynchronism  in  their  designs  to  ensure  predictabil¬ 
ity.  In  fact,  most  real-time  systems  we  have  analyzed  are  more  synchronous  than  tradi¬ 
tional  circuits,  and  have  been  successfully  verified  using  the  method  proposed  [13,14,16]. 

The  main  limitation  of  our  approach  is  the  inherent  complexity  of  the  model  checking 
problem.  Constructing  the  model  has  an  exponential  asymptotic  complexity  in  the  number 
of  components  and  there  are  no  guarantees  that  our  algorithms  will  terminate  in  any  prac¬ 
tical  sense.  However,  we  have  achieved  good  success  in  this  area;  in  most  cases  verifica¬ 
tion  is  performed  in  minutes,  even  for  complex  real-world  systems.  It  must  be  said, 
however,  that  these  problems  are  inherent  to  formal  verification  of  timed  systems,  and  that 
we  know  of  no  approach  that  has  solved  them. 
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The  remainder  of  the  chapter  gives  an  overview  of  the  proposed  method.  We  describe  how 
a  real-time  system  is  modeled  as  a  state-transition  graph,  and  present  the  Verus  language, 
used  to  describe  the  system  being  verified.  We  then  briefly  explain  how  the  verification 
algorithms  work,  and  how  these  results  can  be  used  to  analyze  real  systems.  We  conclude 
the  chapter  by  outlining  the  main  contributions  of  this  work. 

1.3.1  Modeling  a  Real-Time  System 

A  model  of  the  system  in  our  algorithms  is  a  labeled  state-transition  graph  M.  The  labels 
correspond  to  the  values  of  the  variables  in  the  program,  and  transitions  correspond  to  the 
passage  of  time  in  the  model.  The  key  to  the  efficiency  of  the  algorithms  is  to  use  HDDs  to 
represent  the  labeled  state-transition  graph  and  to  verify  if  the  formula  is  true  or  not. 

In  this  method  transitions  are  represented  by  boolean  formulas.  A  formula /represents  a 
transition  between  states  s  and  /  iff  the  formula  is  true  when  we  substitute  the  variable 
values  in  states  s  and  5'  for  the  variables  in /(using  different  variables  for  current  and  next 
state).  The  formula /is  represented  by  a  BDD.  Details  about  this  representation  can  be 
found  in  Section  4.1  and  [8,62]. 

Lazy  composition 

In  the  vast  majority  of  cases  a  real-time  system  is  described  by  a  set  of  processes  that  exe¬ 
cute  concurrently.  Given  the  transition  relation  for  each  process,  a  parallel  composition 
algorithm  constructs  the  global  transition  relation  of  all  processes  and  their  interaction. 
The  composition  algorithm  is  essential  to  the  verification  of  non-trivial  real-time  systems. 
It  is,  however,  extremely  expensive.  The  number  of  states  of  a  composed  model  can  be 
exponential  in  the  number  of  processes.  The  complexity  of  the  composition  algorithm  is 
the  main  limiting  factor  on  the  size  of  systems  being  verified.  We  propose  a  new  approach 
in  process  composition  called  lazy  composition.  The  basic  idea  is  to  avoid  composing  pro¬ 
cesses  whenever  possible,  performing  the  operation  only  when  necessary. 
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With  the  new  technique  the  composition  algorithm  is  applied  at  each  time  the  verifier 
computes  the  image  or  pre-image  of  a  state  set.  When  computing  the  image  of  a  state  set  S, 
we  are  only  interested  in  transitions  that  start  in  S.  At  this  point  the  lazy  composition  algo¬ 
rithm  reduces  the  transition  relations  of  each  process  by  simplifying  and  possibly  eliminat¬ 
ing  transitions  that  do  not  start  in  S.  The  resulting  transition  relations  are  often  much 
simpler  than  the  original  ones,  while  preserving  all  transitions  that  start  in  S.  The  simpli¬ 
fied  relations  are  then  composed  and  the  normal  image  computation  algorithm  can  be 
applied.  Significant  gains  in  time  and  space  during  verification  can  be  accomplished  by 
this  method. 

1 .3.2  The  Verus  Language 

We  have  designed  a  new  language  to  be  used  as  the  specification  language  for  the  real¬ 
time  systems  verified.  The  main  goal  of  this  language  is  to  allow  engineers  and  designers 
to  describe  real-time  systems  easily  and  efficiently.  It  is  an  imperative  language  with  a 
syntax  resembling  that  of  C.  Special  primitives  are  provided  to  express  of  timing  aspects 
such  as  deadlines,  priorities,  and  time  delays.  The  available  data  types  are  integer  and 
boolean.  Nondeterminism  is  supported,  which  allows  partial  specifications  to  be 
described.  The  language  constructs  have  been  kept  simple  in  order  to  make  an  efficient 
compilation  into  a  state-transition  graph  possible.  Smaller  representations  can  then  be  gen¬ 
erated,  which  is  critical  to  the  efficiency  of  the  verification  and  permits  larger  examples  to 
be  handled. 

There  are  several  other  languages  for  specifying  finite-state  real-time  systems.  However, 
they  are  suited  for  different  applications,  and  usually  only  allow  a  natural  description  of 
characteristics  that  are  typical  of  those  applications.  For  example.  Lustre  [72]  and  Signal 
[37]  are  languages  for  describing  sequential  circuits.  They  are  declarative  languages,  and 
in  this  sense  they  resemble  the  SMV  language  [62],  used  for  describing  circuits  in  our 
original  symbolic  model  checker.  In  these  languages  one  describes  explicitly  the  relation¬ 
ship  between  variables,  but  not  the  flow  of  control.  Imperative  languages  take  the  opposite 
approach,  by  explicitly  describing  the  control  flow.  Declarative  languages,  however,  do 
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not  provide  a  natural  way  of  describing  real-time  programs,  usually  implemented  on 
imperative  languages.  In  fact,  our  experience  with  SMV  was  the  motivation  for  develop¬ 
ing  Veras. 

Esterel  [5],  on  the  other  hand,  is  an  imperative  language,  better  suited  for  describing  pro¬ 
gram!  Its  syntax,  however,  may  be  very  unfamiliar  to  most  designers  of  real-time  sys¬ 
tems,  used  to  program  in  C  or  similar  languages.  Moreover,  Esterel  constructs,  unlike 
those  of  Veras,  have  not  been  designed  to  simplify  modeling  real-time  systems.  For  exam¬ 
ple,  specifying  the  execution  of  a  periodic  process  with  a  deadline  is  not  as  straightfor¬ 
ward  as  in  Veras.  Finally,  Esterel  is  a  deterministic  language;  it  does  not  allow  the 
expression  of  nondeterminism.  Modechart  [47]  is  another  example  of  real-time  specifica¬ 
tion  language.  It  is  a  graphical  language  in  which  nodes  represent  states,  and  transitions 
are  explicitly  drawn  between  states.  This  language,  however,  is  more  restrictive  than 
Veras  due  to  its  graphical  nature.  Complex  constructs  such  as  periodic  may  be  difficult 
to  draw.  Moreover,  it  is  an  explicit  state  enumeration  language,  since  individual  states  are 
drawn  in  the  program.  Many  systems  are  too  large  to  be  naturally  described  using  graphi¬ 
cal  languages. 

A  different  approach  is  taken  in  Spin  [43]  and  Murtp  [30].  These  systems  use  languages 
that  resemble  C,  but  that  have  actually  a  significantly  different  semantics.  Modeling  a  sys¬ 
tem  originally  written  in  C  in  one  of  these  systems  may  cause  confusion  between  a  similar 
syntax,  but  different  semantics.  Moreover,  both  systems  are  better  suited  to  verify  asyn¬ 
chronous  designs.  Their  languages  have  been  designed  to  allow  the  straightforward 
expression  of  such  systems.  It  is  not  clear  how  natural  or  efficient  it  is  to  write  a  synchro¬ 
nous  program  in  one  of  these  languages. 

1.3.3  Verification  Algorithms 

In  the  previous  section  we  have  described  how  to  model  a  real-time  system  in  a  form  ame¬ 
nable  to  formal  analysis.  This  section  will  describe  the  algorithms  that  perform  this  analy¬ 
sis.  The  types  of  properties  that  can  be  expressed  are  also  discussed. 
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Real-Time  CTL  Model  Checking 

Computation  Tree  Logic,  CTL,  is  the  temporal  logic  used  in  our  verification  system 
[19,20].  In  CTL  it  is  possible  to  express  properties  such  as  “p  will  eventually  occur”,  or  “p 
will  never  be  asserted”.  However,  it  is  not  possible  to  express  bounded  properties  such  as 
“p  will  occur  in  less  than  10ms”  directly.  Properties  such  as  this  can  only  be  expressed 
using  nested  next  state  operators.  However,  the  resulting  formula  can  be  very  complex  and 
cumbersome  to  work  with.  The  bounded  until  operator  overcomes  this  restriction  by 
allowing  bounds  on  all  CTL  operators  to  be  specified  [33].  It  has  the  form:  U[^  where 
[a,  b]  defines  the  time  interval  in  which  the  property  must  be  true.  Informally, g  is 
true  of  some  path  if  g  holds  in  some  future  state  s'  on  the  path,/is  true  in  all  states  between 
state  s  at  the  beginning  of  the  path  and  s',  and  the  distance  from  s  to  /  is  within  a  and  b. 
All  other  CTL  temporal  operators  are  defined  in  terms  of  the  bounded  until  [11].  The  logic 
obtained  by  augmenting  CTL  with  bounded  operators  is  called  RTCTL. 

The  new  logic  allows  many  important  properties  of  real-time  systems  to  be  verified.  For 
example,  we  have  used  it  to  show  the  existence  of  priority  inversion  [66]  in  a  real-time 
system  [11].  In  this  example,  we  have  modeled  a  simple  real-time  system  in  which  pro¬ 
cesses  communicate  in  a  non-regular  pattern.  The  main  objective  is  to  determine  which 
problems  can  arise  from  this  communication  and  how  to  avoid  them.  The  bounded  until 
operator  has  allowed  us  to  determine  the  existence  of  priority  inversion,  and  to  check  that 
the  solution  implemented,  priority  inheritance,  avoids  the  problem. 

We  have  also  used  RTCTL  model  checking  in  several  other  occasions  to  verify  time 
bounded  properties  of  real-time  and  non  real-time  systems.  Some  examples  include  veri¬ 
fying  that  an  industrial  communications  circuit  would  not  meet  its  timing 
specification  [78]  and  the  verification  of  the  generalized  railroad  crossing  example  [40]. 
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Quantitative  Aigorithms 

Most  verification  algorithms  assume  that  timing  constraints  are  given  explicitly  in  some 
notation  like  temporal  logic.  Typically,  the  designer  provides  a  constraint  on  response  time 
for  some  operation,  and  the  verifier  automatically  determines  if  it  is  satisfied  or  not. 
Unfortunately,  these  techniques  do  not  provide  any  information  about  how  much  a  system 
deviates  from  its  expected  performance,  although  this  information  can  be  extremely  useful 
in  fine-tuning  the  behavior  of  the  system. 

We  present  algorithms  that  determine  the  minimum  and  maximum  length  of  all  paths  lead¬ 
ing  from  a  set  of  starting  states  to  a  set  of  final  states.  We  also  present  algorithms  that  cal¬ 
culate  the  minimum  and  the  maximum  number  of  times  a  specified  condition  can  hold  on 
a  path  from  a  set  of  starting  states  to  a  set  of  final  states.  Our  algorithms  provide  insight 
into  how  well  a  system  works,  rather  than  just  determining  whether  it  works  at  all.  They 
enable  a  designer  to  determine  the  timing  characteristics  of  a  complex  system  given  the 
timing  parameters  of  its  components.  This  information  is  especially  useful  in  the  early 
phases  of  system  design,  when  it  can  be  used  to  establish  how  changes  in  a  parameter 
affect  the  global  behavior  of  the  system. 

Several  types  of  information  can  be  produced  by  this  method.  Response  time  to  events  is 
computed  by  making  the  set  of  starting  states  correspond  to  the  event,  and  the  set  of  final 
states  correspond  to  the  response.  Schedulability  analysis  can  be  done  by  computing  the 
response  time  of  each  process  in  the  system,  and  comparing  it  to  the  process  deadline.  Per¬ 
formance  can  be  determined  in  a  similar  way.  The  algorithms  have  been  used  to  verify 
several  real-time  and  non  real-time  systems.  Several  examples  of  systems  verified  are  dis¬ 
cussed  in  later  chapters. 

Selective  Quantitative  Analysis  and  Intervai  Model  Checking 

The  algorithms  described  above  compute  the  minimum  and  maximum  time  delays  along 
every  possible  execution  sequence  of  a  real-time  system.  In  many  situations,  however,  we 
may  be  interested  in  computing  time  delays  that  relate  only  to  a  subset  of  the  execution 
sequences  that  satisfy  a  given  property.  For  example,  in  the  aircraft  controller  example 
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[13]  the  time  between  requesting  the  activation  of  the  weapons  and  their  actual  firing  time 
is  computed.  The  maximum  time  in  that  example  is  infinity.  The  weapons  may  never  fire 
because  the  firing  sequence  can  be  aborted.  It  may  be  the  case,  however,  that  the  designers 
want  to  compute  the  maximum  response  time  of  the  weapon  subsystem  provided  that  no 
abort  occurs. 

We  propose  a  method  for  specifying  and  verifying  properties  such  as  these.  The  user  can 
restrict  the  set  of  paths  that  will  be  considered  by  specifying  a  property  that  must  be  satis¬ 
fied  in  all  paths  traversed.  This  property  is  expressed  using  linear-time  temporal  logic 
(LTL).  Special  model  checking  techniques  [22]  are  then  used  to  ensure  that  only  paths  that 
satisfy  the  formula  are  considered  by  the  algorithms. 

1 .3.4  Analysis  of  the  results 

The  power  of  our  method  comes  mostly  from  the  different  types  of  analysis  that  can  be 
performed  with  the  results  produced  by  the  algorithms.  This  section  explores  different 
ways  in  which  these  results  can  be  used  to  extract  the  correctness  of  a  design,  its  perfor¬ 
mance  and  insight  into  its  behavior. 

The  basic  algorithms  compute  minimum  and  maximum  time  delays  between  two  state  sets 
start  and  final.  We  can  use  them  to  determine  response  time  to  events  by  applying  the 
algorithms  to  the  predicates  start  =  event  and  final  =  response.  Such  numbers  also  give 
information  about  the  correctness  of  a  design.  If  the  maximum  is  less  than  infinity  then 
event  always  implies  response  in  the  future: 

MAX(evenr,  response)  < iff  AG(event  — >  AF  response) 

Notice  that  a  similar  statement  can  associate  a  minimum  value  to  the  existence  of  a  path. 
This  shows  that  our  algorithms  can  express  the  same  properties  as  these  specific  CTL  for¬ 
mulas.  It  can  be  argued  that  CTL  can  express  more  complex  properties  than  those 
described  above.  However,  properties  such  as  the  one  described  are  certainly  some  of  the 
most  frequently  checked,  and  this  correspondence  is  extremely  useful  in  practice. 
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The  minimum  and  maximum  algorithms  can  also  be  used  to  perform  the  schedulability 
analysis  of  a  real-time  task  set.  We  can  compute  bounds  on  the  execution  time  of  all  pro¬ 
cesses,  and  check  if  they  are  within  the  corresponding  deadlines.  That  also  gives  the  user 
information  about  the  load  on  the  system:  maximum  execution  times  close  to  the  deadline 
indicate  high  load.  We  have  applied  this  technique  to  various  real-time  systems,  such  as 
the  aircraft  controller  described  in  [13].  Non  real-time  systems  can  also  benefit  from  this 
analysis.  We  can  compute  response  time  for  any  event  in  the  system,  and  check  the  perfor¬ 
mance  against  the  specifications.  These  results  can  provide  information  that  may  have  sig¬ 
nificant  impact  in  market  acceptance  when  compared  to  the  expected  behavior  or 
competitor  products.  For  example,  a  correct  product  may  have  a  performance  bottleneck 
that  may  compromise  the  performance  of  the  whole  system.  If  the  bottleneck  cannot  be 
identified  and  corrected,  the  product  may  lose  its  market  share  due  to  poor  performance. 
We  have  applied  this  method  to  the  verification  of  the  PCI  local  bus  [15]. 

The  algorithms  that  count  the  number  of  times  a  condition  occurs  in  a  path  can  be 
extremely  useful  in  this  analysis  as  well.  Given  a  condition  to  be  counted  and  two  events 
start  and  final,  these  algorithms  compute  the  minimum  and  maximum  number  of  times 
condition  holds  on  any  path  from  start  to  final.  They  make  it  possible  to  determine  even 
more  detailed  information  about  the  system.  For  example,  in  real-time  systems  it  is  possi¬ 
ble  to  compute  information  such  as  priority  inversion  time  by  making  start  and  final 
‘request  for  execution’  and  ‘end  of  execution’  at  a  certain  priority  level  respectively,  and 
the  condition  to  be  counted  to  be  ‘executing  at  lower  priority’.  In  non  real-time  systems 
for  example,  it  is  possible  to  compute  the  overhead  associated  with  processing  of  data  by 
making  start  a  ‘request  for  transaction’, the  ‘end  of  transaction’,  and  condition  to  be 
‘data  being  processed’. 

Another  way  in  which  designers  can  benefit  from  this  method  is  by  fine-tuning  the  system 
for  optimal  performance.  After  computing  the  response  times  for  important  events,  the 
designer  can  change  parameters  in  the  model  and  check  how  the  response  times  are 
affected.  In  this  way  it  is  possible  to  optimize  performance  by  determining  the  effect  of  the 
parameters  on  the  global  behavior.  Even  finer  tuning  is  possible  by  using  selective  quanti- 
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tative  analysis.  For  example,  a  very  useful  practice  is  to  optimize  the  performance  for  the 
most  common  case,  while  maintaining  the  correctness  of  uncommon  cases.  Selective 
quantitative  analysis  can  be  used  to  restrict  the  model  to  the  common  cases.  Optimization 
can  then  be  performed  on  this  model.  Finally,  the  complete  system  can  be  checked  for  cor¬ 
rectness  by  removing  the  selection  condition. 

Several  real-time  systems  have  been  analyzed  using  the  method  proposed.  One  example  is 
the  aircraft  controller  described  in  [60].  This  control  system  is  characterized  by  a  set  of 
real-time  tasks,  each  controlling  one  subsystem  of  the  aircraft.  We  have  modeled  this  con¬ 
trol  system  and  analyzed  it  using  the  algorithms  described.  We  have  been  able  to  deter¬ 
mine  the  schedulability  of  the  task  set  and  to  determine  the  response  times  for  specific 
events  of  the  system  such  as  how  long  it  takes  from  the  moment  the  pilot  presses  the  firing 
button  until  the  weapons  are  actually  fired. 

Another  example  that  we  have  analyzed  is  a  robotics  system  used  in  nuclear  plants  to  mea¬ 
sure  the  shape  of  pipes  by  moving  around  them  with  a  distance  sensor  [38].  We  have  been 
able  not  only  to  determine  the  schedulability  of  this  task  set  but  also  to  discover  inefficien¬ 
cies  in  the  design.  The  results  produced  by  the  algorithms  also  suggested  optimizations. 
The  modified  design  has  also  been  analyzed  by  the  same  algorithms.  It  has  a  lighter  load 
and  data  is  consumed  faster  than  in  the  original  design. 

Other  systems  that  have  been  analyzed  include  a  medical  monitoring  system,  the  PCI 
Local  Bus  and  a  distributed  real-time  system.  In  all  these  cases  we  have  been  able  to  ana¬ 
lyze  the  correctness  and  performance  of  the  system,  and  in  most  cases  optimize  it  using 
the  method  proposed. 


1 .4  Summary  and  Main  Contributions 

In  this  work  we  propose  a  new  method  for  the  formal  verification  of  real-time  systems. 
The  method  allows  a  detailed  and  accurate  analysis  of  the  behavior  of  the  system  and  is 
efficient  enough  to  be  used  in  the  verification  of  real  systems.  We  have  used  it  to  analyze 
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several  complex  systems.  The  analysis  performed  using  this  method  not  only  demon¬ 
strates  the  correctness  of  the  design,  but  in  many  cases  it  can  uncover  ambiguities  in  the 
behavior  that  might  be  difficult  to  find  otherwise. 

Verus  extends  previous  methods  in  several  directions.  It  allows  the  natural  expression  of 
many  types  of  real-time  systems  that  occur  in  practice  via  a  language  especially  designed 
to  simplify  the  description  of  timing  characteristics  such  as  periods  and  deadlines.  Previ¬ 
ous  languages  cannot  in  general  be  used  as  efficiently  because  they  either  do  not  have  the 
primitives  needed  to  express  timing  characteristics  (e.g.  SMV  [62]),  lack  nondeterministic 
features  (e.g.  Esterel  [5])  or  can  be  more  restrictive  than  the  language  proposed  (e.g. 
Modechart  [47]). 

Moreover,  many  other  verification  methods  such  as  model  checking  cannot  directly  verify 
several  types  of  properties  that  can  be  checked  in  a  straightforward  way  in  Verus.  Time 
bounds  and  other  quantitative  information  such  as  the  number  of  occurrences  of  events  in 
the  system  are  examples  of  properties  that  cannot  be  easily  obtained  using  standard  model 
checking.  Analyzing  the  performance  and  determining  the  timing  characteristics  of  a 
model  is  very  simple  in  Verus,  but  it  is  not  possible  (except  to  a  very  limited  extent)  with 
traditional  model  checking  or  reachability  based  systems.  For  example,  model  checkers 
can  only  check  time  bounded  properties  by  expressing  them  using  nested  next  state  opera¬ 
tors.  The  resulting  formula,  however,  is  often  very  large  and  cumbersome,  and  impractical 
to  work  with.  Quantitative  information  can  be  obtained  by  adding  counters  that  flag  the 
occurrence  of  the  event  of  interest,  and  checking  that  the  value  of  the  counter  is  within  a 
certain  range.  However,  adding  counters  is  an  expensive  operation,  signiflcantly  increas¬ 
ing  the  complexity  of  the  verification. 

Even  though  it  allows  the  expression  of  a  richer  set  of  timing  properties  than  standard 
model  checking,  the  rate  monotonic  theory  is  also  more  limited  than  the  Vems  approach  in 
many  aspects.  The  description  of  a  system  verified  by  RMS  has  to  fit  a  very  rigid  structure. 
For  example,  tasks  have  to  be  periodic  or  to  be  modelled  using  an  sporadic  server  (see 
[70]  and  Section  2.2.2);  synchronization  has  to  follow  protocols  such  as  priority  inherit- 
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ance  (see  [66]  and  Section  2.2.2)  which  can  be  very  restrictive.  Any  deviation  from  this 
structure  has  to  be  reformulated  or  the  system  cannot  be  verified.  In  some  cases  it  is  possi¬ 
ble  to  change  the  system  description  to  allow  the  verification,  for  instance,  by  describing 
an  aperiodic  processes  using  an  aperiodic  server,  but  in  many  cases  this  is  not  possible. 

Distributed  systems  represent  an  important  class  of  systems  in  which  modifying  the  sys¬ 
tem  description  may  be  insufficient  to  correctly  analyze  its  timing  behavior.  To  date,  RMS 
has  required  the  imposition  of  intermediate  deadlines  to  analyze  distributed  systems  [69]. 
However,  intermediate  deadlines  significantly  change  system  behavior.  In  Verus  there  are 
no  restrictions  on  the  structure  of  the  system;  any  Verus  program  can  be  verified.  More¬ 
over,  RMS  allows  the  expression  of  a  very  limited  type  of  property;  basically  it  computes 
the  maximuTn  execution  times  of  tasks  in  the  system.  Even  though  a  large  number  of  inter¬ 
esting  properties  can  be  expressed  using  this  paradigm,  this  may  be  very  difficult  in  some 
cases.  On  the  other  hand,  in  Verus  it  is  possible  to  determine  the  temporal  relation  between 
any  two  events  in  the  system.  For  example,  counting  the  number  of  occurrences  of  arbi¬ 
trary  events  in  specific  intervals  is  a  property  that  is  simple  to  express  in  Verus,  but  diffi¬ 
cult  to  express  in  RMS. 

In  most  verification  techniques  it  is  possible  to  extend  its  expressive  power  by  changing 
the  system  to  fit  the  limitations  of  the  algorithms  and  verify  a  modified  model.  For  exam¬ 
ple,  a  counter  can  be  introduced  to  represent  the  number  of  occurrences  of  an  event,  and  a 
CTL  formula  can  be  written  stating  that  the  counter  never  overflows.  However,  modifying 
the  system  may  introduce  additional  errors,  or  hide  existing  ones.  Some  properties  similar 
to  those  verified  by  Verus  can  be  checked  using  model  checking  or  RMS  by  introducing 
modifications  to  the  system  (such  as  the  aperiodic  servers  or  intermediate  deadlines 
described).  But  even  in  these  cases,  one  important  advantage  of  Verus  is  that  it  allows  the 
verification  of  these  properties  without  changing  the  model,  ultimately  performing  a  more 
accurate  analysis. 

One  example  of  a  system  that  has  been  verified  using  Verus  that  might  have  been  difficult 
to  verify  using  other  techniques  is  the  distributed  real-time  system  described  in 
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section  6.6.  It  is  a  large  complex  system  which  has  three  main  components:  a  network  to 
which  audio  and  video  sources  are  connected,  a  multi-processor  bus  transporting  this  data 
and  the  destination  processor  for  it.  In  this  example,  we  analyze  the  time  it  takes  for  data 
to  traverse  the  various  components  of  the  system.  The  type  of  quantitative  analysis  per¬ 
formed  cannot  be  done  directly  using  model  checking  or  reachability  based  techniques. 
The  system  cannot  be  easily  described  in  RMS  because  it  is  a  distributed  system  (limita¬ 
tions  on  the  ability  of  RMS  to  handle  distributed  systems  are  discussed  in  [69]).  Finally, 
because  it  is  a  large  system,  it  is  not  likely  that  a  continuous  time  method  would  be  able  to 
handle  its  complexity. 
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This  chapter  will  present  the  two  methods  for  analyzing  real-time  systems  that  are  most 
closely  related  with  the  proposed  approach:  symbolic  model  checking  and  rate  monotonic 
scheduling.  The  algorithms  used  by  Veras  have  been  derived  from  symbolic  model  check¬ 
ing  algorithms.  The  analysis  performed  is,  however,  derived  from  the  rate  monotonic  the¬ 
ory.  Knowledge  about  these  methods  is  not  a  required  prerequisite,  but  it  can  simplify 
understanding  the  Veras  approach. 


2.1  Temporal  Logic  Symbolic  Model  Checking 

Extensive  simulation  is  currently  the  most  widely  used  verification  technique  for  finite- 
state  systems.  However,  simulation  cannot  usually  cover  all  possible  behaviors  of  a  com¬ 
puting  system.  Traditional  simulation  is  too  expensive,  and  non-exhaustive  simulation  can 
miss  important  events,  especially  if  the  number  of  states  in  the  system  being  verified  is 
large.  Other  approaches  for  verification  include  theorem  provers,  term  rewriting  systems, 
and  proof  checkers.  These  techniques,  however,  are  usually  very  time  consuming,  and 
require  user  intervention  to  a  large  degree.  Such  characteristics  limit  the  size  of  the  sys¬ 
tems  they  can  verify  in  practice. 
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Temporal  logic  model  checking  [19,20]  is  an  alternative  approach  that  has  achieved  signif¬ 
icant  results  recently.  Efficient  algorithms  are  able  to  verify  properties  of  extremely  large 
systems.  In  this  technique,  specifications  are  written  as  formulas  in  a  propositional  tempo¬ 
ral  logic  and  computer  systems  are  represented  by  state-transition  graphs.  Verification  is 
accomplished  by  an  efficient  search  procedure  that  views  the  transition  system  as  a  model 
for  the  logic,  and  determines  if  the  specifications  are  satisfied  by  that  model. 

There  are  several  advantages  to  this  approach.  An  important  one  is  that  the  procedure  is 
completely  automatic.  The  model  checker  accepts  a  model  description  together  with  spec¬ 
ifications  written  as  temporal  logic  formulas  and  determines  if  the  formulas  are  true  or  not 
for  that  model.  Another  advantage  is  that,  for  most  formulas  of  interest  (e.g.  safety  formu¬ 
las)  if  the  formula  is  not  true,  the  model  checker  will  provide  a  counterexample.  The  coun¬ 
terexample  is  an  execution  trace  that  shows  why  the  formula  is  not  true.  This  is  an 
extremely  useful  feature  because  it  can  help  locate  the  source  of  the  error  and  speed  up  the 
debugging  process.  Another  benefit  is  the  ability  to  verify  partially  specified  systems.  Use¬ 
ful  information  about  the  correctness  of  the  system  can  be  gathered  before  all  the  details 
have  been  determined.  This  allows  the  verification  of  a  system  to  proceed  concurrently 
with  its  design.  Consequently  verification  can  provide  valuable  hints  that  will  help  design¬ 
ers  eliminate  errors  earlier  and  define  better  systems. 

Properties  to  be  verified  are  described  as  formulas  in  a  propositional  temporal  logic.  The 
system  for  which  the  properties  should  hold  is  given  as  a  state  transition  graph.  It  defines  a 
model  for  the  temporal  logic  since  the  semantics  of  the  logic  are  given  in  terms  of  state 
transition  graphs.  The  model  checker  traverses  this  graph  and  verifies  if  the  model  satisfies 
the  formula.  Checking  that  a  single  model  satisfies  a  formula  is  much  simpler  than  proving 
that  a  formula  is  valid  for  all  possible  models.  Because  of  this  fact  model  checkers  can  be 
more  efficiently  implemented  than  theorem  provers.  The  first  algorithms  [19]  use  adja¬ 
cency  lists  to  represent  the  transition  graph  and  have  polynomial  complexity  in  the  size  of 
the  model  and  in  the  length  of  the  formula.  These  systems  are  able  to  handle  graphs  with 

up  to  10^  states. 
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Recently,  more  efficient  algorithms  have  been  developed  using  symbolic  techniques.  In  the 
new  approach  the  transition  relation  is  represented  implicitly  by  boolean  formulas,  and 
implemented  by  binary  decision  diagrams  [6].  This  usually  results  in  a  much  smaller  rep¬ 
resentation  for  the  transition  relation,  allowing  the  size  of  the  models  being  verified  to 

increase  to  more  than  10  states. 


2.1 .1  Computation  Tree  Logic 

Computation  tree  logic,  CTL,  is  the  logic  used  by  SMV  to  express  properties  that  will  be 
verified  [20].  Computation  trees  are  derived  from  state  transition  graphs.  The  graph  struc¬ 
ture  is  unwound  into  an  infinite  tree  rooted  at  the  initial  state,  as  seen  in  figure  2.  The  tree 
is  infinite  because  no  final  states  are  considered,  only  infinite  paths.  Paths  in  this  tree  rep¬ 
resent  all  possible  computations  of  the  program  being  modelled.  Formulas  in  CTL  refer  to 
the  computation  tree  derived  from  the  model.  CTL  is  classified  as  a  branching  time  logic 
because  it  has  operators  that  describe  the  branching  structure  of  this  tree. 


Figure  1.  A  state  transition  graph  and  the  corresponding  computation  tree 

Formulas  in  CTL  are  built  from  atomic  propositions,  where  each  proposition  corresponds 
to  a  variable  in  the  model,  boolean  connectives  -i  and  a,  and  temporal  operators.  Each 
operator  consists  of  two  parts:  a  path  quantifier  followed  by  a  temporal  operator.  Path 
quantifiers  indicate  that  the  property  should  be  true  of  a//  paths  from  a  given  state  (A),  or 
some  path  from  a  given  state  (E).  The  temporal  quantifier  describes  how  events  should  be 
ordered  with  respect  to  time  for  a  path  specified  by  the  path  quantifier.  They  have  the  fol¬ 
lowing  informal  meanings: 
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•  F  /(fholds  sometime  in  the  future)  is  true  of  a  path  if  there  exists  a  state  in  the  path  that 
satisfies  /. 

•  G/Cfholds  globally)  is  true  for  a  path  if /is  satisfied  by  all  states  in  the  path. 

•  X/ (/"holds  in  the  next  state)  means  that/is  true  in  the  next  state  of  the  path. 

•  f\]  g  (/holds  until  g  holds)  is  satisfied  by  a  path  if  g  is  true  in  some  state  in  the  path, 
and  in  all  preceding  states, /holds. 

Formally,  the  syntax  for  CTL  can  be  defined  by: 

•  Every  atomic  proposition  p  is  a  CTL  formula. 

•  If/ and  g  are  CTL  formulas,  then  so  are  ^/,/ v  g,  EX/,  EG/and  E|/U  g]. 

The  semantics  of  CTL  formulas  are  defined  with  respect  to  a  labeled  state-transition 
graph,  which  is  a  5-tuple  M  =  (P,  S,  L,  N,  Sq),  where  P  is  a  set  of  atomic  propositions,  S  is 
a  finite  set  of  states,  L  is  a  function  labeling  each  state  with  a  set  of  atomic  propositions,  N 
c  S'  X  5  is  a  transition  relation,  and  Sq  is  the  set  of  initial  states.  A  path  is  an  infinite 

sequence  of  states  Sq  si  S2—  ,  such  that  N(si,  is  true  for  every  i. 

If/ is  true  in  a  state  5  of  structure  M,  we  write  M,sl=f.  We  write  M  l=fif  M,  s  f=ffoT  all 
states  5  in  Sq.  The  satisfaction  relation  is  defined  inductively  as  follows  (Given  the  model 

M,  we  abbreviate  M,  s  |=/by  s  f=f): 

1.  If/ is  the  atomic  proposition  v  e  P,  then  5  |=/if  and  only  if  v  e  L(s). 

2.  st=  -i/iff  it  is  not  the  case  that  ^  [=/. 

3.  st=fvg  iff  s  f=for  5  t=  g. 

4.  5 1=  EX/iff  there  exists  a  path  ;c  =  5o  S2...  starting  at  j'  =  5o>  such  that  1=/. 

5.  5 EG/iff  there  exists  a  path  n  starting  at  5  such  that  for  every  state  5'  on  k,  s'  t=f. 

6.  s^=  E[f  U  g]  iff  there  exists  a  path  it  =  ^2-  starting  at  5  =  5o  and  some  i  >  0  such 

that  Si  ^  g  and  for  all  j  <  i,  Sj  \=f. 
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The  following  abbreviations  are  used  in  CTL  formulas: 

f  A  g  =  V  — I  g) 

AX/s-,EX-./ 

EFf=E[trueVf\ 

AF /=  “1  EG  —I  f 
AG  f=  — I EF  — I  f 

A[f  U  g]  =  -I  E[-i  g  U  -1/ A  -1  g]  A  — I  EG  -I  g 

Some  examples  of  CTL  formulas  are  given  below  to  illustrate  the  expressiveness  of  the 
logic. 

•  AG  (req  AF  ack):  It  is  always  the  case  that  if  the  signal  req  is  high,  then  eventually 
ack  will  also  be  high. 

•  EF  {started  a  -i  ready):  It  is  possible  to  get  to  a  state  where  started  holds  but  ready 
does  not  hold. 

•  AG  EF  restart:  From  any  state  it  is  possible  to  get  to  a  state  where  restart  holds. 

•  AG  {send  -4  k[send  U  recv\):  It  is  always  the  case  that  if  send  occurs,  then  eventually 
recv  is  true,  and  until  that  time,  send  must  remain  true. 

2.1.2  Symbolic  Model  Checking 

Early  model  checking  algorithms  represent  the  transition  graph  by  adjacency  lists  [19].  All 
existing  states  are  explicitly  enumerated.  However,  the  number  of  states  in  the  model  can 
be  exponential  in  the  number  of  concurrent  components  in  the  system.  This  frequently 
causes  state  explosion  problems.  The  size  of  systems  that  can  be  verified  is  severely  lim¬ 
ited.  Symbolic  model  checking  represents  states  and  transitions  using  boolean  formulas. 
This  usually  generates  smaller  representations,  because  it  can  automatically  eliminate 
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redundancy  in  the  graph.  Implementing  these  boolean  formulas  as  BDDs  leads  to  very 
efficient  algorithms  for  model  checking  that  are  able  to  verify  much  larger  systems  than 
previous  ones.  This  section  explains  the  symbolic  model  checking  approach. 

Binary  Decision  Diagrams 

Binary  decision  diagrams  (BDD)  are  an  efficient  way  to  represent  boolean  formulas. 
BDDs  often  provide  a  much  more  concise  representation  than  traditional  representations 
like  conjunctive  normal  form  or  disjunctive  normal  form.  They  can  also  be  manipulated 
very  efficiently  [6].  Another  advantage  offered  by  BDDs  is  that  they  provide  a  canonical 
representation  for  boolean  formulas.  This  means  that  two  boolean  formulas  are  logically 
equivalent  if  and  only  if  they  have  isomorphic  representations.  It  greatly  simplifies  the 
execution  of  operations  that  are  performed  frequently  like  checking  equivalence  of  two 
formulas  or  deciding  if  a  given  formula  is  satisfiable  or  not.  Because  of  all  these  character¬ 
istics,  BDDs  have  found  application  in  the  implementation  of  many  computer  aided 
design  and  verification  tools. 

BDDs  can  be  better  understood  by  first  considering  how  boolean  formulas  can  be  repre¬ 
sented  by  binary  decision  trees.  The  nodes  in  the  decision  tree  correspond  to  the  variables 
of  the  formula.  Descendants  of  a  node  are  labelled  with  true  ox  false.  The  value  of  the  for¬ 
mula  for  a  given  assignment  of  values  to  the  variables  can  be  found  by  traversing  the  tree 
from  root  to  leaf.  At  each  node  the  descendant  labelled  with  the  value  of  that  variable  is 
chosen.  Each  leaf  corresponds  to  a  particular  assignment  to  the  variables,  and  contains  the 
truth  value  of  the  formula  for  that  assignment. 

This  representation  is  not  particularly  compact,  because  it  may  store  the  same  information 
repeatedly  in  different  places.  BDDs  are  derived  from  binary  decision  trees,  but  their 
structure  is  a  directed  acyclic  graph  instead  of  a  tree.  Redundant  information  in  the  struc¬ 
ture  is  avoided  by  sharing  common  subtrees.  As  in  decision  trees,  nodes  are  visited  in 
sequence,  from  root  to  leaf.  Note  that  BDDs  impose  a  total  ordering  in  which  the  variables 
occur  in  this  sequence.  This  order  is  preserved  for  all  BDDs  in  use  at  the  same  time.  For 
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example,  the  BDD  shown  in  figure  1  represents  the  formula/  ={a  Ab)v  (c  Ad)  using  the 
ordering  a<b  <c  <d  for  the  variables. 

Given  an  assignment  for  the  variables  in /we  can  decide  if  this  assignment  satisfies  the 
formula  by  traversing  the  BDD  from  root  to  leaf.  At  each  node  we  follow  the  path  that 
corresponds  to  the  value  assigned  to  the  variable  in  the  node.  The  leaf  indicates  if  the  for¬ 
mula  is  satisfied  or  not  for  that  particular  assignment.  Notice  that  redundancy  is  eliminated 
in  two  ways.  Common  subtrees  are  not  replicated,  as  can  be  seen  in  the  figure  below  on 
the  paths  when  a  is  false  and  when  b  is  false.  Also,  when  all  the  leaves  of  a  subtree  have 
the  same  value,  the  subtree  is  eliminated,  and  a  leaf  of  that  value  is  inserted  at  its  place.  In 
the  figure,  when  a  and  b  are  both  true  a  subtree  containing  the  variables  c  and  d  is  elimi¬ 
nated  because  all  of  its  leaves  would  have  the  value  1. 


Figure  2.  BDD  for  formula  {a  Ab)v  (c  Ad) 

For  any  boolean  formula  there  exists  a  unique  BDD  for  a  given  variable  ordering  [6].  The 
BDD  size  is  critically  dependent  on  the  variable  ordering.  It  is  exponential  in  the  number 
of  variables  in  the  worst  case.  Given  a  good  variable  ordering,  however,  the  size  is  linear 
in  many  practical  cases.  Using  a  good  variable  ordering  is  very  important,  but  finding  the 
optimal  order  is  in  itself  an  exponential  problem.  Nevertheless,  there  are  many  heuristics 
that  work  quite  well  in  practice. 
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Efficient  algorithms  exist  to  handle  boolean  formulas  represented  by  BDDs.  Given  BDD 
representations  for/and  g,  algorithms  for  computing  -i/and/  v  g  are  given  in  [6].  Algo¬ 
rithms  for  quantification  over  boolean  variables  and  substitution  of  variable  names  are 
also  required  by  the  model  checker.  It  is  simple  to  compute  the  restriction  of  a  formula/ 
with  a  variable  v  set  to  0  or  1.  We  will  denote  the  restriction  off  with  v  set  to  0  by/|v=o> 
and  the  restriction  of/ with  v  set  to  1  by/lv=i.  The  formula  3v  [/]  is  defined  asf\^  v 
/l^l,  and  Vv[/]  is  defined  as  -i3v[  -./].  Variable  substitution  can  be  accomplished  using 
the  quantification  algorithm. /<v  w)  denotes  the  substitution  of  variable  w  for  variable  v 
in  formula/.  It  is  computed  as/{v  4—  w)  =  3  v  [(v  w)  a/].  These  operations  are  per¬ 
formed  very  frequently  in  the  model  checker,  and  more  efficient  algorithms  are  used  in  the 
actual  system.  These  algorithms  can  be  found  in  [8]. 

Representing  the  Model 

The  key  to  the  efficiency  of  the  algorithm  is  to  use  BDDs  to  represent  the  labeled  state- 
transition  graph  and  to  verify  if  the  formula  is  true  or  not.  The  representation  used  in  Veras 
is  the  same  as  the  one  used  by  symbolic  model  checking.  Details  can  be  found  in 
Section  4.1  and  [8,62]. 

By  definition,  time  passes  by  one  time  unit  at  each  transition.  This  does  not  restrict  the 
models  that  can  be  verified  by  the  method,  because  non-unit  transitions  can  be  modeled  as 
a  sequence  of  unit  transitions.  Nondeterministic  transition  times  can  also  be  implemented 
in  the  same  way,  by  using  stuttering  [1 1]. 

Frequently  a  model  is  described  by  a  set  of  processes  that  execute  concurrently.  Given  a 
set  of  processes  and  a  state-transition  graph  for  each,  a  parallel  composition  algorithm  is 
used  to  construct  a  global  transition  system  in  which  all  processes  execute  concurrently. 
Two  composition  models  are  normally  implemented  by  model  checking:  synchronous  and 
asynchronous  composition.  In  synchronous  composition,  all  processes  transition  at  the 
same  time,  while  in  asynchronous  composition  only  one  transitions.  In  asynchronous 
composition  the  choice  of  which  process  executes  is  non-deterministic  and  fairness  is  used 
to  avoid  starvation  [62].  Both  models  are  implemented  using  BDDs. 
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The  composition  algorithm  is  extremely  expensive;  it  often  generates  an  exponential  num¬ 
ber  of  states  in  the  composed  graph.  However,  the  efficiency  of  symbolic  model  checking 
and  the  fact  that  our  method  uses  discrete  time  allows  the  use  of  composition  in  several 
practical  systems  without  state  explosion  problems. 

Fixpoint  characterization 

Consider  a  labeled  transition  graph  M  with  set  of  states  S.  We  can  denote  a  lattice  of  pred¬ 
icates  over  5  by  Pred,  where  each  predicate  is  identified  with  the  set  of  states  in  5  that 
make  it  true,  and  use  set  inclusion  as  ordering.  A  functional  F  that  maps  Pred(S)  to 
Pred{S)  is  called  a  predicate  transformer.  Informally,  Pred(S)  is  a  set  of  states,  and  F  is  a 
function  from  sets  of  states  to  set  of  states. 

As  described  in  [25],  if  a  predicate  transformer  F  is  monotonic,  it  has  a  least  fixpoint  Ifp 
ZEFCZ)]  =  U,-  Fifalse)  and  a  greatest  fixpoint  gfp  Z[F(Z)]  =  n,-  F\true).  We  can  compute 
both  fixpoints  by  iteration.  Starting  with  Z®  =  false  (for  Ifp)  or  Z®  =  true  (for  gfp),  we  have 
2*+!  _  2'  (j  F(Z')  for  Ifp  and  Z*"^^  =  Z'  n  F(Z)  for  gfp.  The  fixpoint  is  found  when  Z'  = 
Z*'''^  If  the  number  of  elements  in  Pred(S)  is  finite,  termination  is  guaranteed,  because 
there  can  be  no  infinite  sequence  of  Z's  such  that  Z*  ^  Z'’’’^ 

We  can  identify  each  CTL  formula/ with  the  predicate  {5 1  M,s  }  in  Pred{S)  (this  is  the 

set  of  states  that  satisfy/).  Then,  we  can  characterize  each  basic  CTL  temporal  operator  as 
a  fixpoint  of  an  appropriate  predicate  transformer.  The  set  of  states  that  satisfy  the  until 
operator  E/U  g]  is  given  by  the  least  fixpoint  of  Z  =  g  v  (/"  a  EX  Z).  Informally  E[f  U  g] 
is  true  at  state  s,  if  either  g  is  trae  in  s,  or /is  true  in  s  and  there  exists  a  successor  state 
where  E\f\]  g]  is  tme.  The  set  of  states  that  satisfy  the  EG/operator  is  given  by  the  great¬ 
est  fixpoint  EG /of  Z  =  / a  EX  Z.  Informally,  this  means  that  EG /holds  in  a  state  s  if  f 
holds  in  s  and  EG /holds  in  a  successor  state  of  s.  Proofs  that  the  characterizations  above 
correspond  to  the  expected  semantics  are  given  in  [25]. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


39 


Related  Approaches 

The  Model  Checking  Algorithm 

Given  a  CTL  formula/and  a  model  M  represented  as  described  above,  the  model  checking 
problem  consists  of  finding  the  set  of  states  in  M  that  satisfy/.  The  model  checking  algo¬ 
rithm  is  defined  inductively  over  the  structure  of  CTL  formulas.  It  accepts  the  formula  as 
an  argument  (and  M  as  an  implicit  argument),  recurses  over  the  structure  of/and  returns  a 
BDD  that  has  one  boolean  variable  for  every  atomic  proposition  in  V.  The  resulting  BDD 
is  true  of  a  state  if  and  only  if/is  true  in  that  state.  The  algorithm  is; 

•  If/is  an  atomic  proposition  p,  return  the  BDD  that  is  true  if  and  only  if  p  is  true.  This  is 
simply  the  BDD  for  p. 

•  If/is  -\gov  g  Ah,  use  the  standard  BDD  algorithms  for  computing  boolean  connec¬ 
tives. 

•  If/is  EX  g,  then  we  must  verify  if  g  is  true  in  a  successor  state  of  the  current  state.  EX/ 
is  true  in  a  state  t  if  and  only  if  there  exists  a  state  s  such  that  g  is  true  in  state  s,  and 
there  exists  a  transition  from  t  to  s\ 

t\-WLgifi3s[g{s)AN(t,s)] 

Where  g{s)  means  the  value  of  formula  g  in  state  s.  This  value  can  be  computed  using 
the  existential  quantification  algorithms  described  previously.  g{s)  is  true  if  and  only  if 
5 1=  g.  However,  this  operation  occurs  frequently,  and  it  is  important  to  compute  it  in  an 
efficient  manner;  efficient  algorithms  for  this  purpose  are  discussed  in  [8]. 

•  If/is  E[g  U  h],  the  BDD  that  represents  the  states  where  E[g  U  h]  is  true  can  be  com¬ 
puted  by  iterating: 

E[glJh]  =  hvigAEXE[gVh]) 

•  If/is  EG  g,  the  algorithm  is  defined  in  a  similar  way.  It  searches  for  the  greatest  fix- 
point  EG  g  instead,  and  uses  the  following  formula: 

EG  g  —  g  A  EX  EG  g 

•  All  other  CTL  operators  are  written  in  terms  of  the  ones  presented. 
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2.1.3  Verus  and  Symbolic  Model  Checking 

Verus  shares  many  important  characteristics  with  symbolic  model  checking,  such  as  the 
use  of  symbolic  algorithms  implemented  by  BDDs.  The  model  is  represented  in  a  similar 
way,  and  the  quantitative  algorithms  have  similar  fixpoint  characterizations.  The  main  dif¬ 
ferences  are  in  the  way  the  system  is  specified,  and  in  the  types  of  results  produced  by  the 
algorithms. 

Most  model  checkers  use  specification  languages  that  have  not  been  designed  to  simplify 
the  specification  of  real-time  systems.  In  some  systems,  such  as  SMV,  the  specification 
language  simplifies  the  description  of  synchronous  circuits.  Writing  a  real-time  program 
in  such  languages  is  difficult  and  error-prone.  Too  much  time  is  spent  trying  to  accommo¬ 
date  the  system  into  the  language  constructs.  Other  verifiers  use  languages  better  suited 
for  describing  timing  constraints  such  as  Esterel,  but  they  usually  have  an  unfamiliar  syn¬ 
tax.  Too  much  time  may  be  spent  learning  the  language  and  in  trying  to  understand  how  to 
represent  the  desired  features  of  the  system.  The  Verus  language,  on  the  other  hand,  uses  a 
syntax  that  is  familiar  to  most  real-time  system  designers.  It  also  has  constructs  that  make 
it  easy  to  express  timing  characteristics.  Because  of  this,  it  is  better  suited  to  specify  the 
real-time  systems  that  will  be  verified  than  most  languages  used  by  other  model  checkers. 

The  most  important  differences,  however,  are  the  results  produced  and  their  analysis. 
Model  checking  concentrates  on  determining  if  events  will  or  will  not  happen  at  some 
point  in  the  future.  This  information  is  essential  in  asserting  the  correcmess  of  a  model,  but 
it  is  not  sufficient  to  assure  predictability  of  a  real-time  system.  Verus  overcomes  this  lim¬ 
itation  by  concentrating  on  the  determination  of  time  bounds  between  events.  This  infor¬ 
mation  provides  important  insight  into  the  behavior  of  the  system.  The  quantitative 
information  produced  by  Verus  cannot  be  easily  produced  by  a  standard  model  checker  or 
reachability  system,  yet  it  is  vital  in  determining  the  correctness  of  a  real-time  system. 
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2.2  Rate  Monotonic  Scheduling  Theory 

Computers  have  been  used  in  critical  situations  for  a  long  time.  Their  ability  to  react  faster 
than  humans  and  to  perform  under  dangerous  conditions  was  foreseen  early  on.  However, 
it  was  also  realized  early  on  that  the  behavior  of  a  computer  system  is  not  always  simple  to 
predict.  In  some  cases  the  interaction  between  the  various  components  in  the  system  can 
cause  a  response  to  be  delayed  unexpectedly,  making  the  system  unpredictable.  However, 
unpredictable  behavior  is  not  acceptable  in  critical  applications.  Because  of  this  a  very 
conservative  approach  was  usually  taken,  by  designing  the  system  to  support  a  signifi¬ 
cantly  larger  load  than  expected.  The  rationale  was  that  if  enough  computing  power  is 
given  to  the  application,  the  response  time  would  be  acceptable  even  for  cases  in  which 
unexpected  delays  occur.  The  erroneous  but  still  common  idea  that  being  real-time  is  the 
same  as  being  fast  may  have  originated  at  this  time. 

This  approach  is  incorrect,  however.  In  some  cases  it  may  work,  because  sometimes  unex¬ 
pected  delays  are  bounded.  However,  there  may  be  situations  in  which  unbounded  delays 
can  occur  caused  by  problems  such  as  priority  inversion  [66].  In  this  case  a  response  may 
never  be  produced.  But  the  approach  of  designing  the  system  to  support  larger  loads  is  not 
a  good  one,  even  in  the  cases  where  it  leads  to  correct  results.  It  is  not  scalable,  and  it  is 
very  expensive  in  general.  In  order  to  be  able  to  design  predictable  systems  it  is  necessary 
to  use  methods  that  determine  a  priori  if  the  system  will  meet  its  timing  requirements. 
These  methods  must  guarantee  that  the  system  is  predictable,  even  if  not  necessarily  fast. 

2.2.1  The  Liu  and  Lay  land  Theory 

Liu  and  Layland  presented  one  of  the  first  techniques  that  addressed  analytically  the  prob¬ 
lem  of  determining  the  predictability  of  a  real-time  system  [59].  The  original  rate  mono¬ 
tonic  scheduling  theory  is  a  subset  of  their  work.  In  this  approach  a  real-time  system  is 
given  by  a  set  of  tasks  that  execute  periodically  on  a  single  processor.  They  have  shown 
how  to  schedule  task  execution  in  order  to  guarantee  that  the  timing  requirements  will  be 
satisfied,  and  to  optimize  resource  utilization.  Their  method  assumes  that; 
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•  All  tasks  are  periodic,  that  is,  they  execute  once  every  t  time  units,  where  r  is  a  parame¬ 
ter  of  the  task.  The  period  of  a  task  is  a  time  interval  of  length  t  such  that  the  union  of 
all  periods  partition  the  time  line  starting  at  time  0.  Tasks  execute  once  every  period, 
and  are  ready  to  execute  at  the  start  of  each  period.  They  have  known,  deterministic 
execution  times. 

•  The  deadlines  for  each  task  are  at  the  end  of  the  period,  that  is,  every  execution  must 
finish  by  the  end  of  the  period.  If  the  deadline  for  any  period  of  any  task  is  not  met,  an 
error  condition  occurs  and  the  system  becomes  unschedulable. 

•  Tasks  do  not  suspend  themselves  during  execution. 

•  Tasks  are  independent  and  can  be  preempted  instantaneously.  Preemption  overhead  is 
assumed  to  be  zero,  that  is,  the  context  switch  time  is  assumed  to  be  negligible. 

•  There  is  no  synchronization  between  tasks. 

Under  these  assumptions  Liu  and  Layland  studied  both  static  and  dynamic  scheduling 
algorithms.  Static  scheduling  assigns  a  fixed  priority  for  each  task,  this  priority  does  not 
change.  Under  dynamic  scheduling  priorities  may  change  in  time. 

Dynamic  Scheduling 

An  example  of  a  dynamic  priority  algorithm  is  the  earliest  deadline  first  algorithm.  Under 
the  earliest  deadline  first  algorithm,  the  process  that  has  the  closest  deadline  is  given  the 
highest  priority.  This  algorithm  guarantees  schedulability  of  task  sets  that  utilize  the  pro¬ 
cessor  up  to  its  full  capacity.  However,  some  practical  problems  associated  with  dynamic 
scheduling  have  not  been  solved  such  as  its  behavior  under  transient  overload,  scheduling 
of  aperiodic  tasks  and  priority  granularity  in  communication  scheduling  [49].  For  this  rea¬ 
son,  static  scheduling  algorithms  are  more  popular  than  dynamic  scheduling  algorithms. 
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static  Scheduling 

The  rate  monotonic  scheduling  algorithm  is  an  example  of  a  static  priority  algorithm.  It 
assigns  higher  priorities  to  tasks  with  shorter  periods.  It  is  an  optimal  static  priority  algo¬ 
rithm  in  the  sense  that  if  a  task  set  can  be  scheduled  using  some  static  priority  algorithm,  it 
can  be  scheduled  using  the  rate  monotonic  scheduling  algorithm. 

Liu  and  Layland  derived  a  sufficient  condition  for  a  task  set  to  be  schedulable  by  the  rate 
monotonic  algorithm  under  the  assumptions  given  above.  A  set  of  n  periodic  tasks  Tj, 
X2,-,  is  characterized  by  a  period  ti  and  an  execution  time  c,-  for  each  task.  The  formula 
Mj  =  Cj/fj-  gives  the  percentage  of  the  time  task  t,-  is  utilizing  the  processor.  The  formula 
U=uq  +  ui+ ...  +  gives  the  total  processor  utilization  for  the  task  set.  If  a  task  set  with 

n  tasks  has  total  processor  utilization  of  at  most  n(2^^”-l)  then  its  schedulability  is  guaran¬ 
teed  under  rate  monotonic  scheduling.  For  large  values  of  n,  this  bound  converges  to 
In  2  »  0.693.  This  is  a  sufficient,  but  not  necessary  condition;  some  task  sets  with  utiliza¬ 
tion  higher  than  this  bound  can  be  schedulable. 

Another  important  result  is  shown  in  [59].  It  states  that  the  longest  response  time  for  any 
invocation  of  task  x,-  occurs  when  all  tasks  start  executing  simultaneously.  The  time  when 
all  processes  request  execution  is  called  critical  instant.  This  result  can  be  used  to  check 
schedulability  in  some  cases  where  the  total  utilization  is  higher  than  the  bounds  described 
above.  It  is  possible  to  guarantee  that  the  task  set  is  schedulable  by  assuming  that  all  tasks 
start  execution  at  the  same  time,  and  checking  if  the  deadline  of  the  first  instantiation  of 
each  task  is  met. 
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2.2.2  Extensions  of  the  Liu  and  Layland  Theory 

The  assumptions  made  by  Liu  and  Layland  are  rather  restrictive.  Many  interesting  real¬ 
time  systems  cannot  be  described  using  their  method.  Moreover,  the  worst  case  bound  of 
0.693  is  very  pessimistic  in  general.  Much  research  has  been  done  to  extend  the  theory. 
This  section  will  briefly  overview  some  of  this  research.  A  more  detailed  presentation  can 
be  found  in  [53]. 

Deadline  not  equal  to  Period 

The  situation  in  which  the  deadline  of  a  task  is  not  equal  to  its  period  was  first  considered 
by  Leung  and  Whitehead  [54]  in  1982.  They  introduced  the  deadline  monotonic  algo¬ 
rithm,  in  which  priorities  are  assigned  inversely  with  respect  to  task  deadline.  They  have 
shown  that  this  algorithm  is  optimal  when  the  deadline  is  smaller  than  the  period,  and  that 
a  task  set  is  schedulable  by  this  algorithm  if  the  first  instantiation  of  each  task  after  a  criti¬ 
cal  instant  meets  its  deadline. 

In  [50,51,64]  the  case  in  which  the  deadline  and  the  period  of  each  task  are  harmonic  has 
been  analyzed.  It  has  been  shown  that  under  these  conditions  the  rate  monotonic  and  the 
deadline  monotonic  algorithms  are  the  same.  A  sufficient  schedulability  condition  similar 
to  Liu  and  Layland’s  is  given  in  [53]. 

Exact  Schedulability  Analysis 

The  schedulability  test  previously  described  is  sufficient,  but  not  necessary.  There  are  task 
sets  that  are  schedulable,  but  fail  the  test.  An  important  result  is  the  exact  analysis  of  the 
schedulability  of  a  task  set,  presented  by  Lehoczky,  Sha  and  Ding  [52]  and  by  Joseph  and 
Pandya  [48].  Let  a  periodic  task  set  Xj,  t2,...,  x„  be  given  in  priority  order  (Tj  is  the  highest 

priority  task).  Under  the  critical  instant  assumption,  let  WjCr)  =  be  the  cumula¬ 
tive  demand  for  processing  by  tasks  Xy,  1  ^  i,  during  the  interval  [0,  i]  (Cj  is  the  execu¬ 

tion  time  of  task  Xy,  and  2}  is  its  period).  In  other  words,  Wi(t)  is  the  demand  for  processing 
by  all  tasks  of  priority  higher  than  or  equal  to  x,-.  The  task  x,-  meets  all  its  deadlines  if  it 
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meets  the  deadline  of  its  first  instantiation  under  the  critical  instant.  This  occurs  if  Wi(t)  =  t 

S 

for  some  time  t  before  the  deadline  of  t/.  Therefore,  the  task  set  is  schedulable  if  this  con¬ 
dition  holds  for  all  tasks:  Vi  3t  Wjit)  <  t.  This  result  can  also  be  used  to  show  that  the  rate 
monotonic  algorithm  can  schedule  task  sets  with  up  to  100%  utilization  when  the  periods 
are  harmonic. 

The  exact  schedulability  analysis  also  studies  the  average  case  behavior  of  the  rate  mono¬ 
tonic  algorithm.  They  have  shown  that  when  periods  are  drawn  from  a  uniform  distribu¬ 
tion  with  a  sufficiently  wide  range  of  values,  task  sets  can  be  scheduled  with  total 
processor  utilization  as  high  as  88  to  92%  on  average.  Their  analysis,  however,  is  beyond 
the  scope  of  this  presentation,  details  can  be  found  in  [52]. 

Task  Synchronization 

Synchronization  of  real-time  tasks  suffers  from  a  serious  problem,  priority  inversion.  This 
happens  when  a  high  priority  task  is  ready  to  execute,  but  is  blocked  by  a  lower  priority 
task,  usually  because  of  synchronization  constraints  [11,66].  Consequently,  the  rate  mono¬ 
tonic  theory  assumes  that  no  synchronization  between  tasks  occurs.  However,  by  studying 
the  priority  inversion  problem,  it  is  possible  to  include  task  synchronization  in  the  rate 
monotonic  theory  in  a  consistent  way. 

A  typical  scenario  in  which  priority  inversion  occurs  is  as  follows:  A  high  priority  task  A 
requests  access  to  a  shared  resource,  which  is  held  by  a  lower  priority  task  C.  It  is  then 
blocked  until  C  releases  the  resource.  However,  a  task  B,  with  priority  higher  than  C  but 
lower  than  A  might  start  executing,  blocking  C  (and  consequently  A)  indefinitely.  This  is 
called  unbounded  priority  inversion. 

The  problem  in  this  case  is  that  C  is  blocking  A,  but  it  is  still  executing  at  its  lower  priority. 
A  solution  to  the  problem  is  to  make  the  lower  priority  task  inherit  the  higher  priority 
whenever  blocking  the  corresponding  task.  This  protocol  is  called  priority  inheritance,  and 
eliminates  the  unbounded  priority  inversion,  making  it  bounded.  One  can  then  compute 
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the  maximum  priority  inversion  time  as  the  longest  possible  access  of  the  shared  resource 
by  C,  and  incorporate  it  into  the  worst  case  execution  time  of  A.  Notice  that  priority  inver¬ 
sion  cannot  be  completely  eliminated  in  the  presence  of  synchronization,  and  no  inherent 
inefficiency  is  introduced  by  this  protocol. 

The  priority  inheritance  protocol  bounds  the  maximum  priority  inversion  time,  but  it  does 
not  avoid  deadlocks.  For  this  reason,  the  priority  ceiling  protocol  was  introduced.  The  pri¬ 
ority  ceiling  of  a  shared  resource  is  defined  as  the  priority  of  the  highest  priority  task  that 
may  access  this  resource.  The  priority  ceiling  protocol  blocks  a  task  trying  to  access  a 

resource  5  if  its  priority  is  not  higher  than  the  priority  of  S*,  the  highest  priority  resource 
currently  being  accessed  by  another  task.  Whenever  accessing  a  resource,  a  task  inherits 
the  priority  of  the  highest  priority  task  it  blocks.  The  priority  ceiling  protocol  has  the  same 
advantages  of  the  priority  inheritance  protocol,  and  in  addition,  it  prevents  deadlocks. 
More  details  on  these  protocols  can  be  found  in  [66]. 

Aperiodic  Tasks 

In  Liu  and  Layland’s  work,  all  tasks  are  periodic.  Scheduling  a  mixture  of  periodic  and 
aperiodic  tasks  can  be  done,  however,  using  the  concept  of  aperiodic  servers.  Aperiodic 
servers  are  periodic  tasks  that  provide  a  resource  for  the  exclusive  use  of  aperiodic  tasks, 
which  can  be  used  on  demand.  To  provide  fast  aperiodic  response  times,  the  server  is 
given  a  high  priority.  Two  different  types  of  aperiodic  servers  have  been  defined,  the 
deferrable  server  [71]  and  the  sporadic  server  [70]. 

The  deferrable  server  algorithm  creates  a  periodic  server  task  with  execution  time  C, 
period  T  and  priority  defined  by  the  rate  monotonic  algorithm.  This  task  has  its  entire 
period  within  which  it  can  use  up  to  C  units  of  execution  to  service  aperiodic  tasks.  At  the 
end  of  the  period  any  unused  portion  of  C  is  discarded.  The  server  capacity  is  renewed  at 
the  beginning  of  the  next  period.  By  being  assigned  high  priority,  the  server  provides  guar¬ 
anteed  response  times  for  high  priority  aperiodic  tasks,  while  maintaining  predictability 
for  periodic  tasks. 
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The  sporadic  server  differs  from  the  deferrable  server  in  its  replenishing  policy.  It  pre¬ 
serves  its  execution  capacity  until  an  aperiodic  request  occurs.  This  request  then  receives 
immediate  service,  using  part  of  the  server’s  capacity.  The  server’s  capacity  is  replenished 
according  to  the  priority  it  is  executing  at.  Whenever  that  priority  level  becomes  active, 
the  replenishing  time  is  set  to  the  current  time  plus  the  server’s  period.  At  that  point  the 
server  capacity  is  replenished  with  the  server’s  execution  time  consumed  since  the  last 
time  its  priority  level  became  active. 

The  advantages  of  the  sporadic  server  over  the  deferrable  server  are  that  it  can  be  treated 
just  like  an  ordinary  periodic  task  for  schedulability  tests,  it  can  run  at  any  priority,  and 
several  servers  at  different  priority  levels  can  be  defined  to  handle  different  types  of  aperi¬ 
odic  traffic.  The  analysis  of  the  task  set  can  be  performed  in  a  straightforward  way, 
because  a  periodic  task  T,-  can  be  transparently  replaced  by  an  equivalent  sporadic  server 

for  schedulability  purposes  [53]. 

2.2.3  Verus  and  the  Rate  Monotonic  Theory 

Both  Verus  and  the  rate  monotonic  theory  are  methods  designed  to  determine  time  bounds 
between  system  events.  However,  they  use  very  different  approaches  to  achieve  that  end. 
The  RMS  theory  assumes  that  the  system  being  verified  satisfies  certain  assumptions 
about  its  behavior  such  as  periodicity  and  synchronization  constraints.  Systems  satisfying 
these  assumptions  behave  in  a  more  predictable  way  than  generic  systems.  They  can  be 
analyzed  using  analytical  methods,  which  then  provide  formulas  that  can  predict  the  tim¬ 
ing  behavior  of  this  restricted  set  of  systems.  Extensions  to  the  original  theory  have 
expanded  the  class  of  systems  that  can  be  analyzed  to  include  several  types  of  systems  that 
occur  in  practice. 

However,  limitations  still  exist  due  to  the  nature  of  the  analysis  performed.  Many  practical 
existing  systems  cannot  be  analyzed,  such  as  systems  with  aperiodic  activity,  but  in  which 
no  aperiodic  server  has  been  introduced.  In  some  cases  the  system  can  be  forced  to  satisfy 
certain  constraints.  For  example  aperiodic  servers  can  be  introduced  in  systems  in  which 
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not  all  tasks  are  periodic.  However,  in  many  situations  this  is  not  possible  or  desirable:  an 
existing  implementation  may  not  use  aperiodic  servers  and  it  may  not  be  possible  to 
change  it.  Verus  does  not  have  such  limitations;  any  Verus  program  can  be  verified.  For 
example,  an  important  class  of  real-time  systems  that  have  to  be  modified  in  order  to  be 
analyzed  by  RMS  is  distributed  systems.  Intermediate  deadlines  have  to  be  imposed  to 
make  the  system  amenable  to  RMS  [69].  In  some  cases  it  is  not  possible  to  modify  the  sys¬ 
tem  in  this  way;  in  other  cases  intermediate  deadlines  can  make  the  system  less  efficient. 
In  Verus  it  is  straightforward  to  analyze  distributed  systems,  one  example  can  be  seen  in 
Section  6.6. 

Another  difference  between  Verus  and  RMS  is  the  type  of  timing  properties  that  can  be 
checked.  RMS  basically  computes  the  maximum  execution  times  of  tasks  in  the  system. 
Verus  allows  the  determination  of  the  timing  relation  between  any  two  events  in  the  sys¬ 
tem.  It  also  allows  a  richer  set  of  properties  that  include  the  maximum  execution  time  as 
well  as  minimum  execution  time  and  the  number  of  occurrences  of  events  in  any  time 
interval.  An  example  of  a  property  that  is  simple  to  express  in  Verus,  but  not  so  simple  in 
RMS  is  the  maximum  priority  inversion  time:  Given  a  high  priority  process  Pq,  how  much 
time  is  spent  with  lower  priority  processes  during  the  time  Pq  is  requesting  execution? 
This  can  be  computed  in  Verus  by  counting  the  number  of  occurrences  of  the  execution  of 
lower  priority  processes  on  intervals  between  Pq  start  and  Pq  finish. 

In  spite  of  all  these  issues,  RMS  does  have  an  important  advantage  over  Verus.  The  algo¬ 
rithms  used  by  RMS  have  a  lower  complexity  than  those  used  by  Verus.  This  is  expected, 
since  the  systems  analyzed  by  RMS  are  well  behaved;  it  is  easier  to  predict  their  behavior. 
Some  large  systems  that  can  be  analyzed  by  RMS  may  generate  Veras  models  that  suffer 
from  state  explosion.  The  best  approach  seems  to  be  to  consider  Veras  and  RMS  as  com¬ 
plementary  tools,  each  having  specific  advantages  and  disadvantages. 
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Language 


3.1  Introduction 

In  order  to  verify  the  correctness  of  a  system,  this  system  must  be  described  in  a  form 
amenable  to  the  verification  algorithms  used.  Many  formal  languages  and  notations  exist 

for  this  purpose,  each  one  suited  to  a  specific  domain^.  For  example,  the  rate  monotonic 
scheduling  algorithm  accepts  as  input  tasks  execution  times  and  periods.  The  system 
description  is  extremely  abstract,  but  it  is  expressive  enough  to  allow  system  analysis. 
Other  languages,  such  as  VHDL  or  SMV,  take  the  opposite  approach,  providing  a  very 
rich  and  detailed  description. 

Most  languages  simplify  the  description  of  certain  types  of  characteristics,  while  possibly 
complicating  the  expression  of  others.  For  example,  the  SMV  language  allows  circuits  to 
be  described  in  a  straightforward  way.  However,  the  description  of  sequential  execution  is 
not  so  simple.  In  fact,  this  observation  led  to  the  development  of  the  Verus  language,  since 
real-time  systems  are  often  described  using  a  sequential  programming  language. 


1.  See  section  1.3.2  for  a  more  detailed  comparison  between  several  languages  used  in  verification  tools. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


51 


The  Verus  Language 

The  main  goal  of  the  Verus  language  is  to  allow  engineers  and  designers  to  describe  real¬ 
time  systems  easily  and  efficiently.  It  is  an  imperative  language  with  a  syntax  resembling 
that  of  the  C  language.  Using  a  syntax  similar  to  a  well  known  language  simplifies  the 
description  of  complex  programs  in  Verus,  since  programmers  take  advantage  of  previous 
knowledge  and  can  master  the  tool  faster.  Forcing  programmers  to  learn  a  new  language 
discourages  the  use  of  the  tool,  and  often  means  that  less  people  will  ultimately  benefit 
from  it. 

The  most  important  characteristic  of  Verus  programs  is  time.  Special  primitives  are  pro¬ 
vided  for  the  expression  of  timing  aspects  such  as  deadlines,  priorities,  and  time  delays. 
These  primitives  make  timing  assumptions  explicit.  A  different  approach  is  taken  by  many 
other  languages,  such  as  C,  that  allow  programs  where  timing  assumptions  are  not  clearly 
stated.  As  a  result,  the  specification  becomes  ambiguous  and  difficult  to  prove  correct.  The 
approach  taken  in  Verus  makes  the  specification  clearer  and  more  complete. 

The  data  types  allowed  are  fixed-width  integer  and  boolean.  Nondeterminism  is  supported, 
which  allows  partial  specifications  to  be  described.  This  guarantees  that  even  though  the 
model  has  a  finite  number  of  states,  a  rich  set  of  systems  can  be  described.  Language  con¬ 
structs  have  been  kept  simple  in  order  to  make  the  compilation  into  a  state-transition  graph 
as  efficient  as  possible.  Simple  constructs  allow  the  precise  expression  of  the  desired  fea¬ 
tures,  since  complex  constructs  sometimes  force  unnecessary  details  into  the  specification. 
Smaller  representations  can  then  be  generated,  which  is  critical  to  the  efficiency  of  the  ver¬ 
ification  and  permits  larger  examples  to  be  handled. 


3.2  Overview  of  Verus 

This  section  provides  an  overview  of  the  language  by  presenting  a  simple  real-time  pro¬ 
gram.  This  program  implements  a  solution  for  the  producer-consumer  problem  by  bound¬ 
ing  the  time  delays  of  its  processes.  No  synchronization  is  needed  if  the  time  delays  of 
producer  and  consumer  are  defined  properly. 
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The  code  for  the  producer  process  is  shown  below.  Variable  p  is  a  pointer  to  the  buffer 
in  which  data  is  stored.  The  producer  initializes  its  pointer  p  to  0  and  the  produce 
variable  to  false.  It  then  enters  a  nonterminating  loop  in  which  items  are  produced  at  a  cer¬ 
tain  rate.  Line  9  introduces  a  time  delay  of  3  units,  after  which  an  item  will  be  produced. 
Line  10  marks  the  production  of  an  item  by  asserting  produce.  In  line  11  the  pointer  is 
updated  appropriately.  Line  12  makes  sure  that  the  event  produce  is  observed.  It  is 
needed  because  the  state  of  a  Verus  program  can  only  be  observed  at  wait  statements.  If 
a  wait  is  not  introduced  in  line  12,  line  13  would  cancel  the  effect  of  the  assertion  of 
produce  before  it  can  be  observed.  This  behavior  is  discussed  in  detail  later. 

1  producer (p) 

2  int  p ; 

3  { 

4  boolean  produce; 

5 

6  p  =  0; 

7  produce  =  false; 

8  while (! stop)  { 

9  wait (3 ) ; 

10  produce  =  true; 

11  p  =  p+1; 

12  wait (1) ; 

13  produce  =  false; 

14  }; 

15  } 


Figure!.  Producer  code 
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Wait  Statements 

An  important  feature  of  Verus  is  illustrated  in  line  9.  In  Verus  time  passes  only  on  wait 
statements.  Lines  6, 7  and  8  execute  in  time  zero  and  time  elapses  only  after  the  loop  con¬ 
dition  has  been  tested.  This  feature  allows  a  more  accurate  control  of  time,  and  eliminates 
the  possibility  of  implicit  delays  influencing  the  results  of  the  verification.  It  also  gener¬ 
ates  models  with  fewer  states,  since  contiguous  statements  are  collapsed  into  one  transi¬ 
tion.  Notice  that  this  feature  affects  the  behavior  of  the  program  significantly.  For 
example,  a  block  of  code  not  containing  the  wait  statement  executes  atomically. 


Nondeterminism 

To  illustrate  another  characteristic  of  Verus,  let’s  assume  that  the  producer  is  not 
required  to  actually  produce  an  item  after  3  time  units,  but  may  instead  leave  the  value  of 
p  unchanged.  This  can  be  modelled  in  Verus  by  changing  line  11  to: 

11  p  =  selectfp,  p+1}; 

The  select  statement  introduces  a  nondeterministic  choice  in  the  program.  The  value  of 
p  after  executing  select  can  be  either  p  or  p+1  (addition  in  Verus  is  defined  modulo  the 
maximum  value  for  the  variable).  These  choices  can  characterize  the  fact  that  the  producer 
may  produce  an  item,  but  it  may  also  not  produce  it.  This  way  we  can  model  both  possibil¬ 
ities  without  having  to  specify  all  the  details  that  are  actually  needed  to  decide  between 
these  two  options.  Besides  hiding  unnecessary  details,  nondeterminism  can  be  used  to  ver¬ 
ify  partial  specifications.  Whenever  the  value  of  a  variable  hasn’t  been  determined  by  the 
design,  nondeterministic  constructs  can  specify  all  possible  values  the  variable  could  take. 
This  approximates  the  behavior  of  the  actual  system  by  exploring  all  possibilities.  As  the 
design  process  evolves,  the  values  can  be  restricted  until  the  correct  behavior  is  deter¬ 
mined.  Nondeterminism  encourages  the  use  of  automated  verification  in  earlier  phases  of 
the  design.  Components  of  the  system  can  be  validated  before  all  modules  have  been  spec¬ 
ified.  In  this  way  errors  can  be  uncovered  before  propagating  to  components  added  later  in 
the  design. 
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16 

consramer(p,  c) 

17 

int  p ,  c ; 

18 

{ 

19 

boolean  consiame; 

20 

21 

c  =  0; 

22 

consume  =  false; 

23 

while  (Istop)  { 

24 

wait (1) ; 

25 

if  (p  !=  c)  { 

26 

consume  =  true; 

27 

c  =  c  -1-  1; 

28 

wait (1) ; 

29 

consume  =  false 

25 

}; 

26 

}; 

27 

} 

Figure  4.  Consumer  code 

The  consumer  process  is  very  similar  to  the  producer.  The  basic  differences  are  that  it 
waits  for  less  time  before  consuming,  and  that  it  only  consumes  if  p  and  c  have  different 
values  (p  ==  c  signals  an  empty  buffer).  Notice  that  the  producer  does  not  check  if 
the  buffer  is  full  before  inserting  another  item.  The  time  delays  of  both  processes  guaran¬ 
tee  that  an  overflow  will  never  occur. 

The  main  function 

As  in  the  C  language,  main  has  a  special  function  in  Verus.  In  this  function  all  processes 
are  instantiated,  and  global  variables  can  be  declared.  The  variables  p  and  c  (used  as 
pointers  in  the  buffer)  are  declared  and  the  producer  and  consumer  processes  are 
instantiated  in  the  main  function  of  the  example  code. 
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Process  instantiation  in  Verus  follows  a  synchronous  model.  All  processes  execute  in  lock 
step,  with  one  step  in  any  process  corresponding  to  one  step  in  the  other  processes.  Asyn¬ 
chronous  behavior  can  be  modeled  by  using  stuttering,  as  described  in  section  6.1.  An 
implicit  instantiation  of  the  main  module  is  assumed,  where  the  code  in  main  executes  as 
another  synchronous  module. 

Specifications  can  also  follow  the  code  as  can  be  seen.  The  specifications  below  compute 
the  minimum  and  maximum  time  between  producing  an  item  and  consuming  it,  as  well  as 
checking  that  a  produce  is  always  followed  by  a  consume. 


28 

main  ( ) 

29 

{ 

30 

int  p ,  c ; 

31 

32 

process  prod  producer (p, 

c)  , 

33 

cons  consumer (p. 

c)  ; 

34 

35 

spec  MIN [prod. produce,  cons . consume] 

36 

MAX [prod. produce,  cons . consume] 

37 

AG (prod. produce  -> 

AF  cons . consume) 

38 

} 

Figure  5.  Producer/consumer  main  function 


Periodic  Execution. 

To  illustrate  different  features  of  Verus  some  extensions  to  the  program  above  are  consid¬ 
ered.  The  first  comes  from  realizing  that  both  processes  will  always  execute,  even  when  no 
data  exists.  For  example,  even  if  the  producer  does  not  generate  items,  the  consumer 
will  execute.  This  can  be  avoided  using  periodic  execution,  where  execution  is  scheduled 
at  specific  points  in  time.  It  can  be  specified  in  Verus  very  easily.  The  producer  process 
can  be  made  into  a  periodic  process  executing  once  every  10  time  units  as  seen  in  figure  6. 
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The  periodic  statement  has  four  parameters,  the  last  being  the  code  that  will  be  exe¬ 
cuted  periodically.  The  first  parameter  is  the  start_time,  which  specifies  how  many  time 
units  the  periodic  code  will  idle  before  starting  its  execution  for  the  first  time.  In  this 
example  it  will  start  immediately.  The  second  parameter  is  the  period.  In  this  case  the 
statements  following  periodic  will  execute  once  every  10  time  units.  The  third  parame¬ 
ter  defines  a  deadline.  It  states  that  the  execution  must  finish  in  less  than  10  time  units 
or  an  exception  will  be  raised  (exception  handling  is  discussed  below).  Execution  may 
take  longer  than  the  sum  of  the  waits  because  of  synchronization  with  other  processes. 

1  producer (p,  c) 

2  int  p,  c; 

3  { 

4  boolean  produce; 

5 

6  p  =  0; 

7  produce  =  false; 

8  periodic (0,  10,  10)  { 

9  wait (3 ) ; 

10  produce  =  true; 

11  p  =  p+1; 

12  wait (1) ; 

13  produce  =  false; 

14  }; 

15  } 

Figure  6.  Periodic  producer 

Deadlines 

Verus  also  allows  the  definition  of  deadlines  independent  of  periodicity.  For  example,  we 
can  specify  that  producer  will  be  an  aperiodic  process,  but  that  it  must  finish  each  itera¬ 
tion  in  less  than  10  time  units: 
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1  producer (p,  c) 

2  int  p,  c; 

3  { 

4  boolean  produce; 

5 

6  p  =  0; 

7  produce  =  false; 


8 

whiled  stop)  { 

9 

deadline (10) 

{ 

10 

wait (3 ) ; 

11 

produce  = 

true  ; 

12 

P  =  p+1; 

13 

wait (1) ; 

14 

produce  = 

false; 

15 

}; 

16 

}; 

17 

} 

Figure  7.  Aperiodic  producer 

Exceptions 

Exception  handling  is  used  to  control  abnormal  situations.  The  only  exception  currently 
defined  in  Verus  is  a  missed  deadline.  It  occurs  when  the  code  inside  a  deadline  or  a 
periodic  statement  does  not  finish  within  the  specified  time.  An  exception  handler 
must  be  specified  for  the  exception  to  take  effect.  If  no  exception  handlers  are  defined,  the 
exception  is  ignored.  Whenever  a  deadline  is  missed  the  code  designated  as  handler  is 
executed.  After  the  execution  of  the  exception  handler  the  rest  of  the  code  inside  the  dead¬ 
line  scope  is  ignored.  Control  is  then  passed  to  the  statement  following  the  deadline  state¬ 
ment.  This  could  be  the  next  instantiation  of  a  periodic  process  when  the  exception  occurs 
inside  a  periodic  statement  or  the  code  after  a  deadline  statement. 
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1  producer (p,  c) 


2 

int  p ,  c ; 

3 

{ 

4 

boolean  produce; 

5 

6 

handler  { 

7 

error  =  1; 

8 

}  for  { 

9 

p  =  0; 

10 

produce  =  false; 

11 

periodic (0,  10,  10)  { 

12 

wait (3 ) ; 

13 

produce  =  true; 

14 

p  =  p+1; 

15 

wait (1) ; 

16 

produce  =  false; 

17 

}; 

18 

}; 

19 

} 

Figure  8.  Exception  handling 

Figure  8  shows  the  typical  exception  handling  mechanism.  Whenever  a  deadline  is  missed 
an  error  flag  is  asserted.  The  verification  procedure  can  then  check  to  see  if  the  error  con¬ 
dition  is  reachable.  In  some  other  applications,  however,  a  different  behavior  may  be  the 
desired  one.  For  example,  a  multimedia  program  might  choose  to  ignore  some  image 
frame  that  hasn’t  arrived,  provided  the  last  n  arrived.  An  exception  handler  to  model  this 
behavior  can  be  easily  written:  whenever  an  exception  occurs,  the  handler  would  record 
the  number  of  the  frame  missed.  If  the  current  missed  frame  is  at  least  n  frames  apart  from 
the  previous  one,  no  error  would  be  issued.  Otherwise  an  error  condition  would  be 
asserted. 
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Priorities 

Priorities  can  also  be  described  in  Verus  in  a  straightforward  manner.  In  the  same  way  that 
the  constructs  shown  above  encapsulate  the  code  they  apply  to, 

priority (3)  { 

} 

can  be  used  to  make  the  producer  process  ran  at  priority  level  3.  If,  for  example,  the 
consumer  runs  at  priority  2,  then  the  producer  will  be  given  priority  over  it  during 
execution. 

Internal  and  External  Variables 

There  are  two  types  of  variables  in  Veras,  internal  and  external.  In  both  cases,  there  is  no 
default  value  for  variables  in  Veras.  Unless  assigned  a  specific  value,  the  value  of  a  vari¬ 
able  is  chosen  nondeterministically  from  all  possible  values  {true  or  false  for  booleans  and 
Q  2width_2  integers).  The  two  types  differ,  however,  regarding  the  rales  that  control 
when  their  value  can  change.  The  value  of  an  internal  variable  changes  only  when  assign¬ 
ments  are  executed.  External  variables  on  the  other  hand  model  the  interaction  of  the 
model  with  the  environment.  They  correspond  to  inputs  from  the  outside  world,  and  the 
program  has  no  control  over  their  value.  Assignments  to  external  variables  are  not  allowed 
and  their  value  can  change  nondeterministically  at  any  transition  of  the  model.  The  decla¬ 
ration  of  external  variables  is  preceded  by  the  extern  keyword.  Internal  variables  are 
declared  without  this  keyword. 


3.3  Verus  Syntax 

This  section  describes  the  syntax  of  Veras  in  more  detail.  Initially  the  basic  statements  and 
how  they  combine  to  form  a  function  are  described.  A  function,  much  like  its  counterpart 
in  C,  is  a  block  of  statements  executed  sequentially.  Finally,  it  is  explained  how  to  instanti- 
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ate  processes  using  functions,  and  how  to  compose  several  processes  in  parallel.  The  syn¬ 
tax  presented  is  abstract  and  unnecessary  details  have  been  oipitted  for  clarity.  In 
particular,  lists  are  not  formally  defined.  The  name  of  an  entity  followed  by  the  keyword 
Jist  is  used  to  specify  a  list  of  entities  of  the  type  given.  For  example  a  list  of  identifiers  is 
denoted  simply  by  identifier  Jist.  Unless  otherwise  specified,  all  lists  are  separated  by 
spaces,  tabs  or  newlines. 

The  Core  Language 

Verus  has  a  core  subset,  which  defines  the  main  characteristics  of  the  language.  The 
remaining  constructs  are  defined  in  terms  of  the  core  language. 

•  Functions 
function_definition  ::= 

identifier  (  identifier  Jist )  declaration  Jist  compound_statement 
Identifier  lists  are  separated  by  commas. 

•  Declarations 

declaration  ::=  typejspecifier  decljdentifierjist ;  | 

extern  type_specifier  decljdentifierjist  ; 

type_specifier  ::=  boolean  |  int 

decljdentifier  ::=  identifier  \  identifier  :  constant. 

Variables  can  be  boolean  and  fixed-width  integers.  This  guarantees  that  the  model  will  be 
finite-state.  The  default  integer  has  8  bits.  In  a  declaration,  an  identifier  can  be  followed  by 
the  number  of  bits  to  override  the  default,  e.g.,  int  c ;  (8  bits)  or  int  c  :  4 ;  (4  bits). 

•  Statements; 

compound_statement  ::=  {  statement  Jist  specification  Jist } 
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Statement  ::=  compound_statement  \ 
expression_statement  \ 
selection_statement  \ 
iteration_statement  \ 
timejstatement  \ 
null 

expressionjstatement  ;  |  assignmentjexpression  ; 
selectionjstatement  ::=  if  (  expression  )  statement  else  statement 
iteration_statement  while  (  expression  )  statement 
time_statement  ::=  wait  (  constant ) 

•  Expressions 

assignment_expression  ::=  identifier  =  expression  \ 

identifier  =  select  {  expressionjist } 

expression  ::=  expression  \  \  expression  \ 
expression  &&  expression  \ 

!  expression  | 
primary_expression 

primary  ^expression  ::=  (  expression  )  \ 

identifier  | 
constant 

Only  boolean  expressions  are  defined  in  the  core  language.  Integers  variables  and  opera¬ 
tions  are  defined  in  terms  of  booleans  using  binary  encoding.  The  select  expression 
allows  for  a  nondeterministic  choice  of  values.  The  value  returned  is  one  of  the  possible 
values  listed,  chosen  nondeterministically.  Expression  lists  are  separated  by  commas. 
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•  Specifications 

specification  ::=  spec  (  ctljormula  ) ;  | 

lain  (  expression,  expression)  ;  | 

max  (  expression,  expression) ;  | 

mincount  (  expression,  expression,  expression)  ;  \ 

maxcount  {  expression,  expression,  expression)  ; 

Extensions  to  the  Core  Language 

The  constructs  described  below  can  be  defined  in  terms  of  the  previous  ones.  They  sim¬ 
plify  Verus  programs,  but  do  not  add  to  the  expressive  power  of  the  language.  We  only 

present  the  additions  to  the  definitions  given  previously. 

•  Statements: 

statement  ::=  nondeterministic_statement  \  schedulejstatement 
selection_statement  ::=  if  (  expression  )  statement 
nondeterministicjstatement  ::=  select  compound_statement 
schedule _statement  ::= 

periodic  (  constant,  constant,  constant)  compound_statement\ 
deadline  (  constant )  compound_statement  I 
handler  compound_statement  for  compound_statement 


•  Expressions: 

expression  ::=  boolean_expression  \  relation_expression  \  int_expression 

relation_expression  ::=  expression  =  =  expression  \  expression  !  =  expression  | 

expression  <  expression  \  expression  >  expression  \ 
expression  <=  expression  \  expression  >=  expression 
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intjexpression  ::=  expression  +  expression  \  expression  -  expression  | 
expression  *  expression  \  expression  /  expression 

Process  instantiation 

Process  instantiation  occurs  in  the  main  function,  using  the  process  keyword. 
statement  ::=  ’pxocBSS  f_instantiation_list 
fjnstantiation  ::=  identifier functionjiame  {identifier Jist) 

Function  instantiation  lists  and  identifier  lists  are  separated  by  commas. 
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This  chapter  describes  the  meaning  of  Verus  programs,  or  in  other  words,  their  expected 
behavior.  It  shows  how  each  construct  in  Verus  relates  to  the  state-transition  model  used 
and  how  this  graph  is  constructed  from  a  Veras  program.  Understanding  how  Verus  pro¬ 
grams  are  translated  into  state-transition  graphs  is  essential  in  order  to  be  able  to  model  the 
system  and  to  interpret  the  results  of  the  verification  correctly. 

The  meaning  of  a  Veras  program  is  a  state-transition  graph.  Section  4.1  explains  how 
state-transition  graphs  are  represented  in  Veras.  In  section  4.2  the  concept  of  wait  graphs 
is  introduced.  Wait  graphs  are  an  abstraction  used  to  keep  track  of  the  control  flow  of  the 
program.  The  formal  semantics  of  the  core  language  is  described  in  section  4.3,  while 
section  4.4  presents  the  semantics  of  the  extensions  to  the  core  language.  Finally, 
section  4.5  discusses  the  semantics  of  concurrent  processes  in  Verus. 


4.1  State-Transition  Graphs  in  Verus 

The  state-transition  graph  constructed  from  a  program  P  is  Gp  =  (Sp,  Ip,  Tp),  where  Sp  is 
the  set  of  states.  Ip  is  the  set  of  initial  states  and  Tp  is  the  transition  relation.  The  set  of 
states  is  defined  by  the  variables  in  the  program.  Each  possible  assignment  to  the  variables 
is  a  state.  Ip  and  Tp  are  defined  by  the  program  as  will  be  seen  shortly. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


65 


The  Semantics  of  Verus 

Symbolic  Representation 

States  are  defined  by  the  assignment  of  values  to  program  variables  (we  assume  that  dif¬ 
ferent  states  have  different  values  for  the  variables,  as  described  in  [62]).  Each  possible 
assignment  to  the  program  variables  is  a  state.  For  example,  if  the  program  has  three  bool¬ 
ean  variables  a,  b  and  c,  examples  of  states  are  {a,b,c),  (a,b,c)  and  (a,b,c),  where,  for  vari¬ 
able  V,  V  means  the  variable  is  true  in  the  state,  and  v  means  the  variable  is  false.  Boolean 
formulas  over  program  variables  can  be  true  or  not  in  a  given  state.  The  value  of  a  boolean 
formula  in  a  state  is  obtained  by  substituting  into  the  formula  the  values  of  the  variables  in 
that  state.  For  example,  the  formula  (a  v  c)  is  true  in  all  states  shown  above.  The  graph 
representation  used  by  Verus  is  a  direct  consequence  of  this  observation.  Sets  of  states  are 
represented  by  boolean  formulas,  where  each  formula  represents  the  set  of  states  in  which 
the  formula  is  true.  For  example,  the  formula  true  represents  the  set  of  all  states,  the  for- 
mula.  false  represents  the  empty  set  of  states,  and  the  formula  (a  v  c)  represents  the  set  of 
states  in  which  a  ox  c  are  true.  Because  symbols  are  used  to  represent  states,  algorithms 
that  use  this  method  are  called  symbolic  algorithms. 

Transitions  can  also  be  represented  by  boolean  formulas.  A  transition  T{s,  s')  is  repre¬ 
sented  using  two  sets  of  variables,  one  for  the  current  state  and  another  for  the  next  state. 
Each  variable  in  the  next  state  set  corresponds  to  one  variable  in  the  current  state  set.  If 
state  s  is  represented  by  the  formula/^  over  the  current  state  variables,  and  state  s'  is  repre¬ 
sented  by  formula/^'  over  the  next  state  variables,  then  the  transition  T{s,  ^0  is  represented 
by  the  formula/^  Af'.  For  example,  a  transition  from  state  {a,b,c)  to  state  {a,b,c)  is  repre¬ 
sented  by  the  formula  -lO  a  a  -ic  a  -a'  Ab'  a  -ic'.  The  transition  relation  of  a  graph  is 
the  disjunction  of  all  transitions  in  the  graph.  The  meaning  of  the  formula  representing  the 
transition  relation  is  the  following:  there  exists  a  transition  from  s  to  /  iff  the  substitution 
of  the  variable  values  for  s  in  the  current  state  variables  and  /  in  the  next  state  variables  of 
the  transition  relation  yields  true. 

In  the  same  way  that  boolean  formulas  represent  sets  of  states,  they  also  represent  sets  of 
transitions.  In  general,  a  formula  can  represent  many  transitions,  making  the  symbolic  rep- 
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resentation  usually  much  smaller  than  an  explicit  enumeration  of  all  transitions.  This  tech¬ 
nique,  also  used  in  [62],  is  one  of  the  reasons  for  the  efficiency  of  symbolic  algorithms. 

The  symbolic  representation  relies  on  the  fact  that  states  are  represented  by  the  values  of 
the  atomic  propositions  in  those  states.  In  order  to  guarantee  that  states  can  be  identified 
uniquely,  we  must  make  the  assumption  that  different  states  have  different  labeling  of 
propositions.  More  formally,  we  assume  that  for  any  two  states  and  $2  in  5,  if  = 
L(52)  then  =  S2-  This  assumption  does  not,  however,  impose  any  restrictions  on  the 
model,  since  extra  atomic  propositions  can  be  added  in  order  to  make  L(si)  IXs-i)  for  dis¬ 
tinct  states  $1  and  S2  [62]. 


4.2  Tracking  the  Control  Flow  —  Walt  Graphs 

The  execution  of  a  Veras  statement  may  change  the  value  of  one  or  more  program  vari¬ 
ables.  In  general,  it  changes  a  given  state  s  into  another  state  s'.  Executing  a  sequence  of 
statements  in  a  given  state  then  generates  a  sequence  of  states.  However,  in  Veras  not  all 
of  those  states  are  observable.  The  state  of  the  program  can  only  be  observed  at  wait 
statements.  When  a  wait  is  executed  all  changes  caused  by  the  execution  of  the  block  of 
statements  since  the  previous  wait  take  effect  at  the  same  time.  Transitions  in  the  graph 
occur  only  when  wait  statements  are  executed. 


wait (1)  ; 
a  =  false; 
c  =  true; 
d  =  d  +  1; 
wait (1) ; 


Figure  9.  Wait  statement  example:  if  sq  is  the  current  state  at  the  first  wait, 
will  be  the  current  state  at  the  second. 
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Each  transition  in  the  graph  corresponds  to  time  elapsing  by  one  unit.  The  statement 
wait  (1)  corresponds  to  one  transition  in  the  graph.  Longer  waits  are  modeled  by  a 
sequence  of  unit  transitions.  This  allows  the  programmer  to  specify  exactly  when  time 
passes,  and  permits  a  more  accurate  model  of  time  than  possible  if  each  statement  takes 
one  time  unit  to  execute. 

It  is  easier  to  understand  the  behavior  of  a  Verus  program  by  concentrating  on  its  wait 
statements.  This  can  be  accomplished  by  translating  the  program  into  a  wait  graph.  The 
wait  graph  corresponding  to  a  Verus  program  is  a  graph  in  which  the  states  are  the  wait 
statements  in  the  program.  It  corresponds  to  an  intermediate  representation  between  the 
Verus  program  and  the  corresponding  state-transition  graph.  It  is  used  only  to  illustrate 
how  this  translation  occurs  and  is  not  actually  constructed.  In  the  discussion  below,  to  dif¬ 
ferentiate  between  distinct  waits,  wait,-  represents  the  occurrence  of  a  wait  statement 
in  the  program.  Subscripts  have  been  added  to  the  sample  program  below  to  aid  the  pre¬ 
sentation,  but  no  subscript  exists  in  actual  programs. 

As  discussed,  each  wait  in  the  program  is  a  state  in  the  wait  graph.  Transitions  between 
waits  are  defined  as  follows.  A  transition  between  wait,-  and  waity  exists  iff  waity  can 
be  reached  from  wait,-  in  the  control  flow  of  the  program  without  going  through  interme¬ 
diate  waits.  The  edges  of  the  wait  graph  are  labelled  by  a  relation  Ty  between  any  two 
states  in  the  state-transition  graph.  This  relation  describes  the  state  changes  caused  by  the 
execution  of  the  statements  between  the  corresponding  waits.  The  constmction  of  this 
relation  is  described  in  the  next  section.  Intuitively,  given  two  states  s  and  s',  Tyis,  s') 
means  that  if  the  execution  of  the  program  is  in  wait,-  and  the  current  state  is  s,  then  there 
exists  a  path  in  the  control  flow  leading  to  wai  ty  (without  intermediate  waits)  and  the  exe¬ 
cution  of  the  statements  on  this  path  will  change  state  s  into  state  s'. 

Notice  that  7“  represents  exactly  all  transitions  from  s  to  s'  in  the  state  graph  such  that  s 
and  s'  are  respectively  the  current  state  of  the  program  before  and  after  control  is  trans¬ 
ferred  from  wait,-  to  waity.  This  makes  it  possible  to  construct  the  state  transition  graph 
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that  corresponds  to  a  given  Veras  program  from  its  wait  graph.  The  set  of  all  relations 
between  wait  statements  represents  all  transitions  in  the  program.  Consequently,  the  dis¬ 
junction  of  all  such  transitions  constitutes  the  transition  relation  of  the  state-transition 


graph  of  the  program. 

001  waitj^(l); 

002  SI; 

003  while  condl  { 
004  if  cond2  { 

005  S2; 

006  wait2(l); 

007  S3; 

008  }  else  { 

009  S4; 

010  wait3(l); 

Oil  S5; 

012  }  ; 

013  S6; 

014  wait4(l); 

015  }  ; 


Figure  10.  A  Veras  program  and  its  corresponding  wait  graph 


Wait  Counters 

Since  each  relation  7-  corresponds  to  a  set  of  transitions,  their  disjunction  should  corre¬ 
spond  to  the  transition  relation  of  the  program.  However,  this  is  not  true  because  7^y  does 
not  contain  information  about  where  it  came  from  (wait,)  and  where  it  leads  to  (waity). 
The  disjunction  of  all  relations  would  not  maintain  consistency  of  the  values  of  variables 
after  the  execution  of  a  sequence  of  waits. 


This  problem  is  solved  by  creating  an  extra  variable  in  the  program  to  record  this  informa¬ 
tion,  the  wait  counter  wc.  Each  wait  statement  is  preceded  by  an  assignment  wc  =  i, 
where  i  is  the  occurrence  number  of  the  wait  statement  (this  assignment  is  introduced  by 
the  compiler;  it  is  not  part  of  the  source  code).  The  relation  Ty  now  contains  information 
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about  where  it  leads  to,  since  the  assignment  wc  =  j  is  introduced  before  waity.  As 
detailed  in  the  next  section,  the  previous  value  of  the  wait  counter  indicates  where  this 
transition  came  from.  Now  T-  has  all  information  needed  to  maintain  consistency  across 
sequences  of  wait  statements,  and  the  disjunction  of  all  relations  between  waits  is  the 
transition  relation  of  the  program. 

Determining  the  Initial  State  Set 

The  initial  state  set  of  a  Verus  program  is  the  state  it  reaches  just  after  executing  the  first 
wait.  In  order  to  compute  the  initial  state  set,  Verus  programs  start  with  an  initial  wait, 
with  the  wait  counter  of  0  (introduced  by  the  compiler).  The  state  of  the  program  at  this 
point,  Sq,  is  represented  by  the  formula  (wc  =  0).  The  initial  state  set  is  defined  as  the  set  of 

states  reached  from  Sq  in  one  transition. 

In  Sq  all  variables  (with  the  exception  of  wc)  have  nondeterministic  values.  In  the  initial 
state  only  those  that  have  been  assigned  before  the  first  wait  in  the  program  will  have 
fixed  values.  The  difference  between  defining  the  initial  state  set  as  or  as  the  states 
reached  from  Sq  in  one  step  is  a  subtle  consequence  of  this  fact.  The  difference  can  be  seen 
in  the  program  below: 

1  main ( ) 

2  { 

3  boolean  a; 

4 

5  a  =  true; 

6  while (true)  { 

7  wait (1) ; 

8  }; 

9  > 


Figure  11.  Initial  state  set  example 
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The  specification  (AG  a)  is  false  if  the  initial  state  set  is  Sq,  because  the  state  set  repre¬ 
sented  by  (wc  =  0  A  -^a)  is  part  of  Sq,  that  is,  a  could  be  false  in  the  initial  state.  However, 
this  behavior  can  be  confusing  to  programmers,  since  it  is  not  intuitive  from  the  program 
source.  Defining  the  initial  state  set  as  the  set  of  successors  of  So  solves  this  problem.  For 
the  program  above  the  initial  state  set  is  (wc  =  1  a  a),  which  models  the  expected  behavior. 


4.3  Core  Language  Semantics 

This  section  formally  defines  the  meaning  of  a  Veras  program.  It  explains  how  the  rela¬ 
tions  between  waits  are  constructed,  and  formalizes  the  construction  of  the  state  graph 
that  models  a  Veras  program. 

The  state  space  of  a  Veras  program  is  defined  by  a  set  of  boolean  variables.  A  state  in  the 
model  is  an  assignment  of  values  to  the  variables.  The  set  of  all  states  is  ST.  A  relation 
between  any  two  states  belongs  to  Relation  =  Powerset{ST  x  ST). 

The  semantics  is  defined  as  a  function  of  the  program  text.  The  meaning  of  a  program  is  a 
transition  relation  between  states  such  that  there  is  a  transition  from  state  s  to  state  s'  iff 
there  exists  an  execution  sequence  leading  from  wait;  to  waity  without  intermediate 

wait  statements  that  changes  state  s  into  state  s'. 

The  function  R  given  below  constructs  the  relations  between  wait  statements.  Intuitively, 
given  a  relation  r  describing  the  program  until  the  execution  of  statement  Stmt,  the  func¬ 
tion  R  will  produce  the  relation  /  describing  the  program  after  executing  Stmt.  The  func¬ 
tion  R  also  constructs  another  relation  t  by  accumulating  the  relations  constructed  for  all 
wait  statements.  Function  R  is  defined  by 

R:  STMT  -»  Relation  x  Relation  Relation  x  Relation 
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where  pairs  of  relations  are  <r,  t),  r  being  the  relation  containing  changes  to  the  program 
state  since  the  last  wait  statement,  and  t  being  the  transition  relation  of  the  program,  that 
is,  the  disjunction  of  the  relations  between  all  pairs  of  wait  statements. 

The  state-transition  graph  corresponding  to  a  program  P  is  constructed  as  follows.  Given 
progrtoi  P,  function  R  constmcts  <r,  t)  =  =  0,  0),  where  t  is  the  transition  relation 

of  the  state-transition  graph  corresponding  to  P,  and  the  initial  state  set  is  constructed  from 
t  as  discussed  above. 

Additional  definitions  are  needed  before  presenting  the  semantic  functions: 

•  There  are  only  boolean  variables  in  the  program.  Integer  variables  are  encoded  in 
binary  and  substituted  for  the  corresponding  boolean  variables. 

•  V  and  V  are  two  sets  of  boolean  variables  such  that  for  each  variable  v  in  the  program 
there  are  corresponding  variables  v  €  V  and  v'  e  V.  The  variable  ve  V  represents  the 
value  of  the  program  variable  v  in  the  current  state,  and  the  variable  v'  e  V  represents 
its  value  in  the  next  state.  A  transition  is  a  relation  between  variables  in  V  and  V. 

•  A  variable  wc  is  introduced  in  the  model.  It  is  used  to  keep  information  about  the  previ¬ 
ous  and  next  wait  statements  in  the  control  flow.  An  assignment  wc  =  i;  is  assumed 
to  exist  just  before  statement  wait;. 

•  An  initial  wait  (with  wait  counter  value  of  0)  is  the  second  statement  of  the  program, 
preceded  by  an  assignment  wc  =  0. 

•  All  programs  are  assumed  to  have  as  the  last  statement: 

while  (true)  wait(l); 

There  are  two  reasons  for  this  requirement.  Transitions  are  only  generated  at  wait 
statements  (see  P[[  wait  J)  and  the  existence  of  a  final  wait  guarantees  that  transi¬ 
tions  will  be  generated  for  all  programs.  Moreover,  this  loop  also  guarantees  that  even 
when  the  program  terminates  and  no  more  statements  are  executed,  the  state  of  the  pro¬ 
gram  can  still  be  observed.  Intuitively  the  loop  means  that  after  the  program  terminates 
its  state  will  remain  unchanged. 
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4.3.1  Expressions 

The  meaning  of  a  Verus  expression  is  a  boolean  formula  corresponding  to  the  syntactic 
expression.  Since  the  core  language  only  allows  boolean  expressions,  the  translation  is 
straightforward;  it  is  described  below  by  the  function  E\ 

Primary  Expressions 

true  J  =  true 
£■[[  false  ]]  =  false 

£[[  V  J  =  v',  where  v  is  an  internal  variable  and  v'  e  Y. 

£[[  V I  =  V,  where  v  is  an  external  variable  and  v  e  K 

Internal  variables  are  represented  by  their  next  state  value,  while  external  variables  are 
represented  by  their  current  state  value.  This  choice  of  representation  significantly  affects 
the  behavior  of  each  type  of  variable,  as  described  below. 

First,  lets  consider  how  internal  variables  behave.  All  references  to  an  internal  variable 
will  be  denoted  by  its  next  state  variable.  For  example,  a  reference  to  variable  v  on  the 
left-hand  side  of  an  assignment  (as  in  v  =  false)  will  be  denoted  by  the  next  state  vari¬ 
able  v',  and  therefore  the  assignment  will  change  the  value  of  v'  in  the  current  relation  (see 
semantics  of  assignments).  This  is  the  expected  behavior,  since  an  assignment  determines 
the  value  of  the  variable  in  the  next  state. 

However,  other  references  to  V  (as  in  X  =  !  v)  also  refer  to  v'.  In  the  assignment  x  =  !v 

the  value  of  x'  in  the  current  relation  will  be  assigned  the  negation  of  the  value  of  v'.  Two 

cases  must  be  considered.  If  variable  v  has  been  assigned  a  value  previously,  this  assign¬ 
ment  has  updated  the  value  of  v'  in  the  current  relation.  Consequently,  the  assignment  to  x 
uses  the  most  recent  value  assigned  to  v.  To  illustrate  how  this  affects  the  behavior  of  the 
program,  consider  the  program  fragment  below.  The  value  assigned  to  x  in  line  4  is  false, 
because  in  the  current  relation  of  the  program  at  line  4  the  value  of  variable  v'  is  true. 
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1  V  =  false; 

2  wait (1)  ; 

3  V  =  true; 

4  X  =  !v; 

Figure  12.  Example  of  the  behavior  of  internal  variables 

In  the  case  where  variable  v  has  not  been  assigned  any  value,  the  current  relation  enforces 

that  the  value  of  internal  variables  do  not  change  via  the  clause  (^y  g  internal  variables  ^  ~  ) 
introduced  in  the  current  relation  at  wait  statements  (see  i?[Iwait]]).  This  clause  guaran¬ 
tees  that  the  current  and  next  state  variables  of  internal  variables  have  the  same  value  (the 
clause  is  automatically  overridden  if  an  assignment  is  made).  This  has  the  effect  that  the 
value  of  an  internal  variable  does  not  change  if  no  assignments  are  made.  This  is  true  even 
across  waits.  For  example,  if  line  3  did  not  exist  in  the  fragment  above,  the  value  of  v' 
would  be  false  in  the  current  relation  because  of  this  clause,  and  therefore  the  value 
assigned  to  x  would  be  true. 

External  variables,  on  the  other  hand,  are  not  included  in  the  wait  statement  clause  intro¬ 
duced  in  the  current  relation.  This  is  because  their  value  is  not  maintained  across  wait 
statements.  External  variables  may  change  value  nondeterministically  at  wait  statements 
and  they  cannot  be  assigned  to.  The  value  an  external  variable  has  at  any  point  in  the  pro¬ 
gram  is  the  value  it  had  in  the  previous  wait  statement,  since  no  assignments  exist.  This 
value  is  represented  by  its  current  state  variable. 

Boolean  Expressions 

E[[  expri  I  I  expr2  ]]  =  expr^  v  expr2 
El  expri  &&  expr2  J  =  expri  a  expr2 
E[[  !  expr  ]]  =  — I  expr 
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4.3.2  Statements 
Assignments 

Rlv  =  expr]i{r,t)  =  {i3y[v  =  Expry/^Ary/^]),t), 

where  v  =  £[[  v  ]],  Expr  =  £[[  expr  I  and  y  is  a  new  variable. 

This  expression  computes  the  strongest  post-condition  for  the  assignment  v  =  expr  given 
r  as  a  pre-condition.  If  r  is  the  set  of  valid  transitions  in  the  graph  since  the  last  wait 
statement,  the  expression  above  determines  the  largest  set  of  transitions  that  satisfy  the 
assignment  and  that  satisfy  r  for  variables  other  than  v.  Intuitively,  this  expression  substi¬ 
tutes  the  previous  value  of  v  in  r  for  Expr,  while  maintaining  the  values  of  other  variables. 

/?[[v  =  select{expri,  expr2}  W,t)  =  ^^t(r',t)  =  Rlv  =  expril{r,t), 

(r",  r>  =  /?I[v  =  expr2  l<r,  r)  in 
</  V  r",  t) 

The  relation  for  a  nondeterministic  assignment  is  the  disjunction  of  the  expression  for 
each  possible  assignment.  In  other  words,  a  nondeterministic  assignment  is  true  if  any 
possible  value  is  assigned.  The  extension  of  R  for  the  case  in  which  more  than  two  expres¬ 
sions  exist  is  a  simple  extension  of  the  disjunction  shown,  and  is  omitted  for  brevity. 

Sequential  Execution 

m  Si ;  $2  ]\{r,  t)  =  Rl  $2  Si  W,  t)) 

Wait  Statements 


/?[[  wait/  ( 1 )  Kr,  t)  =  {{{wc  =  i)  jvV  =  v'),  (t  v  r)), 

where  IV  is  the  set  of  internal  variables  in  the  program. 

Function  R  for  the  wait  statement  changes  the  previous  relation  in  two  ways.  At  this 
point  in  the  program  transitions  that  lead  to  wait,-  are  generated.  These  transitions  are 
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represented  by  relation  r  before  the  wait  is  executed,  which  is  then  disjointed  with  the 
previous  transition  relation  t.  This  is  the  only  statement  that  changes  the  value  of  t. 

Moreover,  the  current  relation  after  the  execution  of  wait,-  must  reflect  the  fact  that  a  new 
set  of  transitions  will  be  computed.  The  new  relation  specifies  that  transitions  start  in 
wait,-  with  the  formula  (wc  =  i),  that  is,  the  wait  counter  value  of  the  current  state  variable 
in  the  transition  will  be  i.  The  destination  of  the  new  set  of  transitions  will  be  established 
when  the  next  wait  statement  is  found.  At  that  point  the  assignment  wc  =  j  before  wai ty 
introduces  the  formula  (wc'  =  j)  in  the  current  relation,  specifying  where  the  transition 
leads  to.  Because  of  these  two  conditions,  all  transitions  specify  a  value  for  both  the  cur¬ 
rent  and  next  state  wait  counters. 

Finally,  it  is  necessary  to  introduce  the  expression  A„  ^  /y  v  =  v'  into  the  current  relation. 
For  internal  variables  this  expression  guarantees  that  unless  assigned  a  new  value,  internal 
variables  maintain  their  previous  value  across  transitions.  External  variables  may  change 
value  during  transitions,  and  therefore  are  not  included  in  this  expression.  This  allows  the 
use  of  the  next  state  variable  as  the  semantic  value  of  internal  program  variables.  When¬ 
ever  an  internal  variable  is  referenced,  its  next  state  variable  will  have  its  previous  value 
(via  the  clause  v  =  v'  above)  or  its  new  value  (via  the  assignment  expression  described 
previously)  in  the  current  relation. 

The  expression  above  handles  only  unit  waits.  Longer  waits  are  modeled  by  a  sequence  of 
unit  wait  statements. 

Conditionals 

Rlif  cond  Si  else  S2  I<r,  t)  =  let  {/,  f)  =  R\[  Si  ]K(r  a  cond),  t), 

{/',  t")  =  Rl  S2  Il<(^  A  -.cond),  t)  in 
{r'vr",t'vt") 
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Each  branch  in  the  if  statement  is  executed  by  restricting  its  parameter  to  the  set  of  tran¬ 
sitions  that  satisfy  the  appropriate  conditional  —  5]  receives  those  transitions  satisfying 
cond,  and  ^2  receives  transitions  not  satisfying  cond.  In  this  way,  if  control  reaches  the  if 
statement  through  a  state  that  satisfies  the  condition,  control  will  proceed  to  5i.  If  the  state 
does  not  satisfy  the  condition,  control  proceeds  to  Si-  The  representation  of  a  conditional 
is  the  disjunction  of  the  representation  of  its  branches. 

Loops 

Rl  while  cond  Si  ]I<r,  t)  =  let  </,  0  =  Rg  while  cond  Si  ]|(/?[[  ]K(r  a  cond),  t}), 

{/',  t")  =  ((r  A  -icond),  t)  in 

The  representation  of  a  while  loop  can  be  seen  as  unrolling  the  loop  into  nested  if  state¬ 
ments;  if  cond  {Si ;  if  cond  {Si, ...} } ; .  However,  even  though  simple  to  understand, 
function  R  for  a  while  statement  cannot  be  computed  as  shown  above,  because  it  is  cir¬ 
cular.  A  more  accurate  definition  can  be  seen  below.  It  uses  the^  operator,  which  returns 
the  least  fixpoint  of  the  functional  given  as  its  argument. 

Rl  while  cond  Si  J  =MWr,t).  let  (/,  f)  =f{Rl  Si  I|((r  a  cond),  t)), 

(r",  t")  =  {(r  A  —icond),  t)  in 
(/  V  r",  t'  V  O) 

The  operations  performed  by  the  functional  above  are  projection  (from  the  result  of  the 
application  of/into  r  and  t'),  disjunction  (of  /,  r"  and  f,  t")  and  pairing  (of  the  results  of 
the  disjunctions).  Since  these  operations  are  continuous  [76],  any  functional  constructed 
from  them  is  also  continuous.  By  being  continuous,  the  functional  is  also  monotonic,  and 
therefore  it  has  a  fixpoint. 

However,  not  all  programs  with  while  statements  have  well  behaved  semantics.  For  exam¬ 
ple,  a  fixpoint  characterization  for  the  program  below  is  the  relation /aZ^c,  which  corre- 
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spends  to  non-termination,  as  is  expected  from  the  program.  But  since  there  are  no  waits 
in  the  program,  time  does  not  pass.  Non-termination  in  this  case  means  that  if  the  program 
is  in  state  s  when  the  code  below  is  executed,  there  will  be  no  outgoing  transition  from  s, 
that  is,  the  non-terminating  behavior  is  not  observable.  In  order  to  avoid  this  anomalous 
behavior,  we  impose  the  rule  that  all  execution  sequences  inside  all  whiles  in  the  pro¬ 
gram  must  execute  at  least  one  wait  statement.  This  ensures  that  even  non-terminating 
while  programs  are  always  observable  and  that  no  states  without  outgoing  transitions 
will  be  created. 

1  while (true)  { 

2  a  =  !a; 

3  } 


Figure  13.  A  while  program  with  a  trivial  fixpoint 


Null  Statement 

/?[[  null  K''.  t)  = 

4.4  Verus  Extension  Semantics 

If  statement 

selection_statement  ::=  if  (  expression  )  statement 

The  if  statement  is  a  simple  extension  of  the  if-then-else  statement,  it  is  simply  translated 
as:  if  (  expression  )  statement  else  null 

Non  Deterministic  Statement 

nondeterministiejstatement  ::=  select  compound_statement 
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The  statement  select  {Sj;  52;-. ;  S„}  has  the  intuitive  meaning  of  a  non  deterministic 
choice  of  execution  between  the  statements  in  the  compound  statement.  It  corresponds  to: 

extern  int  s; 

if  (s  ==  1)  Si  else 
if  (s  ==  2)  S2  else 


Schedule  Statements 

schedule _statement  ::= 

deadline  {  constant )  compoundjstatement 

The  deadline  statement  is  translated  into  the  Verus  core  language  by  creating  an  integer 
variable  timer.  At  the  deadline  keyword  an  assignment  timer  =  0  is  inserted. 
Within  the  scope  of  the  deadline,  each  wait  (n)  statement  is  preceded  by  timer  = 
timer  +  n;  and  by  a  check  if  (timer  >=  deadline)  error_code,  where  the  excep¬ 
tion  handler  defines  errorjcode. 

schedule_statement 

periodic  (  constant,  constant,  constant )  compound_statement 

The  periodic  statement  is  handled  in  a  similar  way.  The  difference  is  that  an  infinite  loop  is 
inserted  enclosing  the  periodic  statement,  and  once  the  periodic  statement  has  finished 
executing,  a  loop  is  inserted  to  enforce  the  periodicity: 

while  (timer  <  period)  { 
timer  =  timer  +  1; 
wait (1) ; 

}; 
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A  similar  loop  is  inserted  before  the  main  loop  at  the  beginning  of  the  periodic  statement 
to  account  for  the  initial  offset. 

Exception  Handling 

schedule _statement  ::= 

handler  compound_statement  for  compoundjstatement 

The  first  compound  statement  is  the  exception  handler,  and  the  second  is  the  scope  of  the 
handler.  The  exception  handling  statement  handler  f  or  ^2  is  translated  by  substitut¬ 
ing  the  error_code  created  by  deadline  statements  in  S2  for:  5^  else  {.  The  compound 
statement  5^  is  executed  in  case  of  a  missed  deadline,  and  the  else  clause  guarantees  that 
the  rest  of  the  deadline  statement  is  skipped  in  case  of  a  missed  deadline.  The  {  after 
the  else  is  closed  at  the  end  of  the  deadline  statement. 

For  example,  the  periodic  producer  described  in  the  previous  chapter  is  translated  into  the 
core  language  as  seen  below: 

1  producer (p,  c) 

2  int  p,  c; 

3  { 

4  boolean  produce; 

5 

6  handler  { 

7  error  =  1; 

8  }  for  { 

9  p  =  0; 

10  produce  =  false; 

11  periodic (0,  10,  10)  { 

12  wait  (3 )  ; 

13  produce  =  true; 
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P  =  P+1; 
wait (1) ; 

produce  =  false; 

}; 

}; 

} 


Figure  14.  Original  periodic  producer 

producer (p,  c) 
int  p ,  c ; 

{ 

boolean  produce; 
int  timer; 

p  =  0; 

produce  =  false; 
while  (true)  { 
timer  =  0 ; 
timer  =  timer  +  3 ; 
if  (timer  >10)  { 

error  =  1 ; 

}  else  { 
wait (3 ) ; 
produce  =  true; 
p  =  P+1; 

timer  =  timer  +  1; 
if  (timer  >10)  { 

error  =  1; 

}  else  { 
wait (1) ; 
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25  produce  =  false; 

26  }; 

27  }; 

28  while  (timer  <  10)  { 

29  timer  =  timer  +  1; 

30  wait(l);  . 

31  }; 

32  }; 

33  } 


Figure  15.  Periodic  producer  in  the  core  language 

Integer  expressions  and  operations 

These  operations  are  translated  into  boolean  equivalents  by  using  a  binary  encoding  of 
integers.  Since  all  integers  have  fixed-width,  this  is  a  straightforward  translation. 


4.5  The  Semantics  of  Concurrency  in  Verus 

up  to  this  point  we  have  seen  how  a  single  process  in  Verus  is  translated  into  the  corre¬ 
sponding  state  transition  graph.  But  more  frequently  than  not  real-time  systems  are 
described  by  a  set  of  concurrent  processes  instead  of  a  single  one.  It  is  possible  to  specify 
concurrent  processes  in  Verus  using  the  process  keyword.  This  section  describes  how 
the  behavior  of  parallel  processes  is  defined  in  Verus. 

Synchronous  Composition 

Given  a  set  of  processes  defined  by  their  state  transition  graphs,  it  is  possible  to  construct 
a  global  state  transition  graph  corresponding  to  the  environment  in  which  all  processes 
execute  concurrently.  The  concurrency  model  implemented  in  Verus  is  synchronous,  that 
is,  one  transition  in  the  global  model  corresponds  to  exactly  one  transition  in  each  process. 
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Given  two  processes  defined  by  their  state  transition  graphs  Gi  =  (5],  /j,  Tj)  and  G2  =  (S2, 
I2,  T2)  we  can  construct  a  global  state  transition  graph  G  =  (S,  I,  T)  by: 

•  5  =  {(5i,  S2)  1 e  Si,  ^2  e  S2  and  5i<v>  =  52<v>,  for  all  shared  variables  v} 

where  j(v>  denotes  the  truth  value  of  variable  v  in  state  s. 

Each  state  in  the  global  model  contains  one  component  in  each  process.  However,  one 
constraint  must  be  satisfied.  If  a  variable  is  referenced  in  more  than  one  process,  its 
value  in  each  component  of  the  global  state  space  must  the  same.  This  model  guaran¬ 
tees  consistency  of  the  values  of  shared  variables. 

•  I  -  {0i»  ^2)  I  ^  h’  h  ^  h  (^1’  ^2)  ^ 

An  initial  state  in  G  is  a  state  in  the  global  model  that  is  an  initial  state  in  all  processes. 
.  r((^i,  52),  (h,  t2))  iff  Tif^i,  ti)  and  12(52,  ^2) 

A  transition  in  the  global  model  exists  iff  it  corresponds  to  existing  transitions  in  each 
component.  Symbolically  T  is  constructed  by  conjuncting  Tj  and  T2-  The  meaning  of 
the  formula  representing  the  global  transition  relation  is  that  a  transition  exists  if  transi¬ 
tions  exist  in  all  components. 

This  construction  allows  the  specification  and  verification  of  systems  in  which  several 
processes  execute  concurrently.  The  synchronous  model  can  be  relaxed  using  stuttering, 
as  discussed  in  section  6.1.  This  model  is  expressive  enough  to  allow  the  description  of 
most  types  of  practical  systems. 

Prioritized  Composition 

Real-time  systems  frequently  use  priorities  to  ensure  that  critical  processes  are  not  delayed 
by  less  important  ones.  Priorities  are  needed  whenever  there  is  contention  for  resources  in 
the  system,  such  as  the  processor.  A  scheduler  is  used  to  decide  which  process  accesses 
the  resource  at  any  time,  and  a  real-time  scheduler  uses  priority  information  to  decide  the 
access  order  for  the  resource. 
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In  Verus  the  scheduler  can  be  implemented  in  the  core  language  to  model  this  behavior. 
Both  static  and  dynamic  priority  schedulers  can  be  implemented.  A  static  priority  sched¬ 
uler  can  be  seen  below.  The  scheduler  receives  requests  from  each  process  (via  the  reqz 
variables),  and  asserts  the  variable  granted,  which  signals  its  decision  about  which  pro¬ 
cess  executes  next. 


1 

scheduler ( reql ,  req2 ,  req3 , 

granted) 

2 

boolean  reql, 

req2 ,  req3 ; 

3 

int  granted; 

4 

{ 

5 

while  (true) 

{ 

6 

if  (reql) 

granted  =  1 ; 

else 

7 

if  (req2) 

granted  =  2 ; 

else 

8 

if  (req3) 

granted  =  3 ; 

else 

9 

granted  = 

0; 

10 

wait (1) ; 

11 

}; 

The  scheduler  chooses  which  process  executes  next  by  following  the  nested  if  structure. 
The  order  in  which  the  requests  are  tested  define  the  priority  order  used. 

Whenever  requesting  execution,  process  pi  sets  variable  reqi  to  true.  When  it  finishes 
executing  it  resets  the  variable.  During  execution  it  must  wait  until  the  variable  granted 
has  its  index  before  proceeding: 


12 

/*  Beginning  of 

execution  */ 

13 

reql  =  true; 

14 

while  (granted  ! 

=  1) 

wait (1) ; 

15 

wait(l);  /*  execute 

for  one  time  unit 

16 

*  •  • 

17 

while  (granted  ! 

=  1) 

wait (1) ; 

18 

wait (1) ; 
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19  /*  End  of  execution  */ 

20  reql  =  false; 

21  wait(l); 

Dynamic  scheduling  can  also  be  implemented.  In  this  case  the  reqi  variables  are  integers 
and  contain  the  priority  level  at  which  the  process  is  requesting  execution.  One  way  of 
defining  the  values  for  the  reqi  variables  is  to  use  the  priority  statement.  The  state¬ 
ment  priority  (n)  {5j  };  is  translated  to: 

reqi  =  n; 

Sv 

reqi  =  0; 


This  can  be  easily  generalized.  For  example  the  earliest  deadline  scheduling  algorithm  can 
be  implemented  by  assigning  to  the  request  variable  the  difference  between  the  current 
time  and  the  deadline.  The  scheduler  now  must  choose  the  process  with  the  highest 
requested  priority: 


1 

2 

3 

4 
6 

7 

8 
9 

10 

11 

12 

13 

14 


scheduler (reql,  req2,  req3 ,  granted) 
int  reql,  req2 ,  req3 ,  granted; 


{ 

while  (true)  { 

if  (reql  >=  req2)  { 
if  (reql  >=  req3) 

}  else  { 

if  (req2  >=  req3) 


}; 

wait (1)  ; 


granted  =  1;  else 
granted  =  3 ; 

granted  =  2;  else 
granted  =  3 ; 
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Many  different  schedulers  can  be  written  to  suit  specific  applications.  For  example,  the 
scheduler  above  always  favors  the  process  with  the  lower  index  in  case  of  equal  priority 
levels.  In  some  cases  this  might  not  be  desirable,  and  the  scheduler  has  to  be  refined  to 
reflect  this  feature  of  the  system. 

Notice  that  issues  such  as  fairness,  absence  of  deadlocks  and  starvation  depend  on  the  spe¬ 
cific  scheduler  being  used.  For  example,  it  can  be  easily  seen  that  fairness  is  not  guaran¬ 
teed  by  the  schedulers  described  above.  They  always  favor  higher  priority  processes,  and 
may  starve  lower  priority  ones.  However,  this  is  allowed  in  real-time  resource  manage¬ 
ment,  and  the  schedulers  are  correct.  Different  schedulers  may  have  different  require¬ 
ments,  and  these  issues  have  to  be  considered  again  if  new  schedulers  are  introduced. 

Prioritized  composition  allows  the  specification  of  many  common  types  of  real-time  sys¬ 
tems  in  a  straightforward  way.  In  fact,  most  of  the  examples  described  in  the  next  chapter 
have  been  implemented  using  this  paradigm. 
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Previous  chapters  have  described  how  to  specify  a  real-time  system,  and  how  to  generate, 
from  the  specification,  a  model  that  is  amenable  to  a  formal  analysis.  This  chapter  will 
describe  in  detail  the  algorithms  used  to  verify  real-time  systems  in  Verus.  The  simplest 
method  consists  of  introducing  time  bounds  on  CTL  operators.  Later  more  powerful  algo¬ 
rithms  will  be  explored  that  introduce  quantitative  and  path  selective  analysis  methods 
into  the  Verus  tool. 


5.1  RTCTL  Model  Checking 

Symbolic  model  checking  eilgorithms  are  able  to  verify  a  large  and  important  class  of 
properties  of  computer  systems  in  general.  Properties  such  as  liveness  and  safety  can  be 
easily  expressed  and  verified.  However,  there  is  an  important  class  of  properties  that  can¬ 
not  be  adequately  handled  using  this  method.  This  class  consists  of  the  properties  which 
place  bounds  on  response  time.  In  CTL  it  is  possible  to  state  that  some  event  will  happen 
in  the  future,  but  the  property  that  some  event  will  happen  at  most  x  time  units  in  the 
future  cannot  be  expressed  directly. 
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A  simple  and  effective  way  to  allow  the  expression  and  verification  of  time  bounded  prop¬ 
erties  is  to  introduce  bounds  in  the  CTL  temporal  operators.  The  extended  logic  is  called 
RTCTL  [33].  The  expressive  power  of  RTCTL  is  the  same  as  CTL,  since  the  bounded 
operators  can  be  translated  into  nested  applications  of  the  EX  (or  AX)  operators.  How¬ 
ever,  this  translation  is  often  impractical,  and  RTCTL  provides  a  much  more  compact  and 
convenient  way  of  expressing  such  properties. 

The  basic  RTCTL  temporal  operator  is  the  bounded  until  operator  which  has  the  form: 

where  [a,b]  defines  the  time  interval  in  which  the  property  must  be  true.  We  say 
that /Ufa  b]  i  true  of  some  path  if  g  holds  in  some  future  state  s  on  the  path, /is  true  in 
all  states  between  the  beginning  of  the  path  and  s,  and  the  distance  from  this  state  to  s  is 
within  the  interval  [a,b]-  The  bounded  EG  operator  can  be  defined  similarly.  Other  tempo¬ 
ral  operators  are  defined  in  terms  of  these. 

More  formally,  we  extend  the  CTL  semantics  to  include  the  bounded  until  operator  by 
adding  the  following  clauses  to  the  formal  semantics  given  in  section  2.1.1: 

7.  5  t=  E\flJ[a,b]  iff  there  exists  a  path  7t  =  ■^2  -  starting  at  j  =  and  some  i  such 

that  a<i<  band  Si  |=  g  and  for  ally  <  i,  Sj  \=f. 

8.  s\=  EG[ay,]/iff  there  exists  a  path  7C  =  .tq  ^2  -  starting  at  j  and  for  all  i  such  that 
a<i<b.  Si  \=f. 

As  an  example  of  the  use  of  the  bounded  until  consider  the  property  “It  is  always  true  that 
p  may  be  followed  by  q  within  3  time  units”.  This  property  can  be  expressed  in  RTCTL  as 
AGip  -»  EFfo  3]  q).  The  bounded  F  operator  is  derived  from  the  bounded  until  just  as  in 

the  unbounded  case,  i.e.  EFfa,^,]/  =  E[true  Ufa,t]/I- 

In  order  to  implement  this  operator,  we  will  use  a  fixpoint  computation  that  is  similar  to 
the  one  implemented  in  CTL  model  checkers.  It  is  easy  to  see  that  the  formula  E/Ufa, i,]  g] 
can  be  expressed  in  the  form: 
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if  >  0  and  b>0:  El/Uj^  g]  =/ a  EX  E[/'U[a-i,fc.]]  g] 

else,  ifb>0:  WlJ[o,b]  g]  =  g  v  (f  a  EX  E[fU[o,i-i]  g]) 

else:  E|/U[o,o]  g]  =  g 

Other  operators  are  defined  similarly. 

Consider  the  first  of  these  cases.  We  compute  the  sets  of  states  where/is  true  for  a  steps. 
During  this  computation,  a  fixpoint  may  be  reached  before  a  iterations  have  passed.  When 
this  happens,  we  can  skip  to  the  second  case.  By  using  this  optimization,  the  number  of 
required  iterations  may  be  reduced  when  the  time  interval  is  large,  but  a  fixpoint  is  reached 
quickly.  The  same  optimization  can  also  applied  in  the  second  case.  If  a  fixpoint  is  reached 
before  b-a  iterations,  with  b  and  a  being  respectively  the  upper  and  lower  bounds  of  the 
operator,  we  can  immediately  proceed  to  the  third  case. 


5.2  Quantitative  Analysis:  Minimum/Maximum  Delay 

Traditional  formal  verification  algorithms  assume  that  timing  constraints  are  given  explic¬ 
itly  in  some  notation  like  temporal  logic.  Typically,  the  designer  provides  a  constraint  on 
response  time  for  some  operation,  and  the  verifier  automatically  determines  if  it  is  satis¬ 
fied  or  not.  These  techniques  do  not  provide  any  information  about  how  much  a  system 
deviates  from  its  expected  performance,  although  this  information  can  be  extremely  useful 
in  fine-tuning  the  behavior  of  the  system. 

This  section  describes  algorithms  to  compute  quantitative  timing  information,  such  as 
exact  minimum  and  maximum  delays  on  the  time  between  a  request  and  the  correspond¬ 
ing  response.  We  also  present  algorithms  that  compute  the  minimum  and  maximum  num¬ 
ber  of  times  a  certain  condition  is  satisfied  on  all  paths  between  two  given  events.  For 
example,  we  can  use  these  algorithms  to  bound  the  time  between  asserting  a  bus  request 
and  the  corresponding  bus  grant.  In  addition,  we  may  need  to  compute  the  number  of 
times  a  third  event  occurs  within  such  an  interval,  such  as  the  number  of  times  other  trans¬ 
actions  are  issued  between  the  bus  request  and  the  corresponding  grant. 
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5.2.1  Minimum  Delay  Algorithm 

The  algorithm  takes  two  sets  of  states  as  input,  start  dxvA  final.  It  returns  the  length  of  (i.e. 
number  of  edges  in)  a  shortest  path  from  a  state  in  start  to  a  state  m.  final.  If  no  such  path 
exists,  the  algorithm  returns  infinity.  In  the  algorithm,  the  function  T{S)  gives  the  set  of 
states  that  are  successors  of  some  state  in  S.  In  other  words,  T{S)  =  {/  I  N{s,  jO  holds  for 
some  5  €  5}.  In  addition,  the  variables  R  and  R'  represent  sets  of  states  in  the  algorithm. 

proc  min  {start,  final) 

1  =  0; 

R  =  start, 

R'  =  T{R)  u  R; 

while  {{R'  ¥=R)  A  (Rn  final)  =  0)  do 
i  =  i+  1; 

R  =  R'; 

R'  =  T(R')(jR'; 
if  (i?  n  final  ^  0) 

then  return  v, 
else  return  <»; 

Figure  16.  Minimum  Delay  Algorithm 

The  first  algorithm  is  relatively  straightforward.  Intuitively,  the  loop  in  the  algorithm  com¬ 
putes  the  set  of  states  that  are  reachable  from  start.  If  at  any  point,  we  encounter  a  state 
satisfying  j/znaZ,  we  return  the  number  of  steps  taken  to  reach  the  state.  Figure  17  shows 
how  the  algorithm  works  by  computing  the  successors  of  the  current  frontier  (the  shaded 
area)  at  each  iteration. 

In  the  formal  proof  of  correctness,  we  use  the  following  notation: 

•  is  the  set  of  states  reachable  in  i  or  fewer  steps  from  a  state  in  start. 

•  L  is  the  length  of  a  shortest  path  from  a  state  in  start  to  a  state  \n  final. 


90 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


Quantitative  Anaiysis:  Minimum/Maximum  Delay 


Figure  17.  Minimum  algorithm:  it  searches  forward  from  S. 

The  correctness  of  the  algorithm  follows  from  the  following  loop  invariants: 

•  i<L 

•  R  =  Si 

•  R'  =  Sm 

We  observe  that  the  three  initializing  statements  insure  that  the  invariants  are  satisfied 
before  entering  the  loop.  Next  we  show  that  the  body  of  the  loop  maintains  the  invariants, 
provided  the  loop  test  is  satisfied. 

•  The  loop  invariant  on  R,  R  =  5/,  and  the  second  half  of  the  loop  test,  R  n  final  =  0 
imply  that  i  <  L,  otherwise  some  state  in  5,-  would  belong  to  final.  This  inequality 
implies  i  +  1  <  L  so  we  can  safely  increment  i  without  violating  the  invariant  on  i. 
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•  The  second  statement  sets  R  to  the  value  of  R',  so  now  R  =  .  This  means  that  R  now 

satisfies  its  invariant  with  the  new  value  of  i. 

•  The  last  statement  sets  R'  to  the  union  of  R'  and  the  image  of  R  .  So  by  construction,  we 
know  that  R'  =  S,+2  Therefore,  R'  satisfies  its  invariant  with  the  new  value  for  i. 

Next  we  argue  about  termination.  By  the  definition  of  5j,  we  must  have  5q  c  Sj  c  S2  £  ••• 
Since  the  number  of  states  is  finite,  only  a  finite  number  of  the  inclusions  can  be  proper, 
and  it  must  be  the  case  that  Sj,  =  Sk+i  for  some  ^  >  0.  From  the  loop  invariant  we  know  that 
R  =  Si  and  R'  =  Si+i,  therefore,  the  loop  cannot  execute  more  than  k  times  without  the  loop 
test  /?'  i?  becoming  false. 

We  finish  the  proof  by  analyzing  what  happens  at  the  final  conditional.  If  R  n  final  ^  0, 
then  by  the  loop  invariant,  R  =  S,-,  there  is  some  5  e  S,-  such  that  5  e  final.  From  the  defini¬ 
tion  of  Sj,  we  know  that  this  state  is  reachable  in  i  or  fewer  steps  from  a  state  in  start.  This 
gives  us  an  upper  bound  on  L,  L  i.  The  invariant  on  /,  however,  is  L  ^  i.  Therefore,  it 
must  be  the  case  that  L  =  i. 

If  the  test  is  false,  then  we  must  have  exited  the  loop  because  R'  =  R.  From  the  invariant,  R 
=  Si  and  R'  =  5,+i;  therefore,  5/  =  This  in  turn  means  that  after  reaching  all  the  states 

in  Si  we  cannot  reach  any  new  states  (all  the  edges  of  states  in  S,-  lead  to  states  in  S,).  The 
false  test  tells  us  that  no  state  in  R  belongs  to  final,  and  we  have  just  argued  that  R  is  the  set 
of  all  reachable  states.  Therefore,  there  is  no  path  from  a  state  in  start  to  a  state  in  final,  so 
we  return  infinity. 

5.2.2  Maximum  Delay  Algorithm 

This  algorithm  also  takes  start  and  final  as  input.  It  returns  the  length  of  a  longest  path 
from  a  state  in  start  to  a  state  in  final.  If  there  exists  an  infinite  path  beginning  in  a  state  in 

start  that  never  reaches  a  state  in  final,  the  algorithm  returns  infinity.  The  function  T  ^(5") 
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gives  the  set  of  states  that  are  predecessors  of  some  state 
holds  for  some  /  e  5"}).  R  and  R'  will  once  more  be  sets 
notjinal  the  set  of  all  states  that  are  not  in  final. 

proc  max  {start,  final) 
i  =  0; 

R  =  true\ 

R'  =  notjinal, 
while  ((/?'  ^R)  A  {R'  n  start  ^  0))  do 
i  =  i+  1; 

R  =  R'; 

R'  =  T'^{R')  n  notjinal, 
if  (/?  =  /?') 

then  return  o®; 
else  return  i; 

Figure  18.  Maximum  Delay  Algorithm 

The  upper  bound  algorithm  is  more  subtle  than  the  previous  algorithm.  In  particular,  we 
must  return  infinity  if  there  exists  a  path  beginning  in  start  that  remains  within  notjinal. 
A  backward  search  from  the  states  in  notjnal  is  more  convenient  for  this  purpose  than  a 
forward  search.  Figure  19  shows  the  maximum  delay  algorithm.  At  each  iteration  it  finds 
the  set  of  states  which  are  the  beginning  of  intervals  with  i  states,  none  satisfying^na/.  Ini¬ 
tially,  i  is  0,  and  the  frontier  is  notjnal  At  the  i*  iteration  the  current  frontier  is  the  set  of 
states  that  are  the  beginning  of  paths  with  i  states  completely  in  notjnal.  We  then  com¬ 
pute  the  set  of  predecessors  (in  notjnal)  of  the  current  frontier.  Those  states  are  the 
beginning  of  paths  with  /+1  states  completely  in  notjnal 

We  use  the  following  two  definitions  in  proving  the  algorithm  correct: 


in  S'  (i.e.  r\S')  =  {s  I  N{s,  s') 
of  states.  Finally,  we  denote  by 
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•  Si  is  the  set  of  states  which  can  be  the  beginning  of  a  path  containing  i  states,  all  con¬ 
tained  in  notjinal. 

•  Mis  the  number  of  states  in  a  longest  path  beginning  inside  start  and  contained  within 
notjinal. 


Figure  19.  Maximum  algorithm:  it  searches  backwards  from  -iF 

Although  ultimately  we  are  interested  in  the  number  of  edges  in  a  longest  path,  it  is  easier 
to  reason  when  we  count  the  number  of  states  in  a  path.  The  correctness  of  the  algorithm 
then  follows  from  the  following  loop  invariants: 

•  i<M 

•  R  =  Si 

•  R'  =  Sm 
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We  observe  that  the  three  initializing  statements  insure  that  the  invariants  are  satisfied 
before  entering  the  loop.  We  can  also  show  that  the  statements  within  the  loop  maintain 
the  invariants,  provided  the  loop  test  is  satisfied. 

•  The  invariant  on  R',  R'  =  5,+i,  and  the  second  half  of  the  loop  test,  R'  n  start  ^  0  imply 
that  i  +  1  <  M.  Therefore,  we  can  increment  i  without  violating  the  invariant  on  i. 

•  The  second  statement  sets  R  to  the  value  of  R'  so  we  know  that  now  R  =  S’j+j.  This 
means  that  R  now  satisfies  its  invariant  with  the  new  value  for  i. 

•  The  third  statement  sets  R'  to  the  inverse  image  of  R'  intersected  with  notjinal.  The 

invariant  gave  us  that  R'  =  Si+i  before  the  assignment.  By  construction,  after  the  assign¬ 
ment  we  have  that  R'  c  5,+2-  For  the  inclusion  in  the  other  direction,  we  observe  that 
any  path  of  i  +  2  states  contained  in  notjinal  can  be  thought  of  as  beginning  in  a  state 
labeled  with  notjinal  that  has  an  edge  to  a  state  that  is  the  beginning  of  a  path  of  i  +  1 
states  labeled  with  notjnal.  In  other  words,  the  states  in  5, +2  states  in  notjnal 

with  an  edge  to  a  state  in  5,+j.  But  these  are  precisely  the  states  just  computed  for  the 
new  value  of  R'  so  we  get  that  ^i+2  c  R'.  This  means  that  R'  also  satisfies  its  invariant 
with  the  new  value  for  i. 

Now  we  argue  about  termination.  First,  it  should  be  clear  from  the  definition  of  Sj  that 
5o  2  *^1  2  “^2  3  ••••  Since  we  are  dealing  with  a  finite  number  of  states,  the  initial  value,  Sq 
must  be  a  finite  set,  which  in  turn  means  that  only  a  finite  number  of  the  inclusions  are 
proper.  Therefore,  it  must  be  the  case  that  S]^  =  Sj^+i  for  some  k>0.By  the  invariant,  R  =  Sj 
and  R'  =  Sj+j;  thus,  the  loop  cannot  execute  more  than  k  times  without  the  loop  test  R'^R 
becoming  false. 

Before  continuing,  we  make  an  observation  about  the  loop  test.  It  can  never  be  the  case 
that  both  parts  of  the  loop  condition  are  false.  If  we  assume  that  both  parts  of  the  loop  con¬ 
dition  are  false,  then  both  R  =  R'  and  Rn  start  =  0  giving  us  that  R  n  start  =  0.  If  we 
then  unroll  the  loop  once,  we  notice  that  at  the  previous  iteration,  R  was  assigned  the  value 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


95 


Verification  Algorithms 

of/?'  which  would  mean  that  we  would  have  had  R'  n  start  =  0  and  we  would  have  exited 
the  loop  at  that  point. 

We  complete  the  proof  by  analyzing  what  happens  at  the  final  conditional.  We  first  con¬ 
sider  the  case  where  we  exit  the  loop  because  R  =  R'.  In  this  case,  we  have  reached  a  fix- 
point.  By  the  invariant,  R  =  and  /?'  =  Si+i,  therefore  we  have  Sf  =  Si+i-  We  argued 
previously  that  the  states  in  have  edges  to  states  in  5,-.  Since  5j+i  =  S^,  we  know  that 
every  state  in  has  an  edge  to  another  state  in  Sj+i-  So  every  state  in  Si+i  is  the  begin¬ 
ning  of  an  infinite  path  of  states  remaining  in  Si+i  c  notjinal.  The  previous  observation 
tells  us  that  /?'  n  start  ^  0,  therefore  some  state  s  e  Sj+i  belongs  to  start.  This  state  then  is 
the  beginning  of  an  infinite  path  starting  at  a  state  in  start,  which  never  reaches  a  state  in 
final,  so  we  return  infinity. 

If  R'  n  start  =  0,  then  by  the  invariant  R'  =  S^+i,  we  know  that  there  is  no  path  of  z  +  1 

states  contained  in  notjinal  beginning  in  a  state  in  start.  No  longer  path  can  exist  since 
this  would  contradict  the  absence  of  a  path  of  i  -i-  1  states,  so  we  have  M  <  i.  But  we  also 
have  the  invariant  i  <  M,  so  it  must  be  the  case  that  M  =  i.  All  edges  coming  out  of  the  last 
state  on  the  path  lead  to  states  in  final  (otherwise  there  would  be  a  longer  path).  Since  the 
transition  relation  is  total,  there  must  exist  at  least  one  such  edge.  Therefore,  the  longest 
path  from  a  state  in  start  to  a  state  in  final  contains  i  +  1  states  and  has  length  i. 


5.3  Quantitative  Analysis:  Condition  Counting 

In  many  situations  we  are  interested  not  only  in  the  length  of  a  path  leading  from  a  set  of 
starting  states  to  a  set  of  final  states,  but  also  in  measures  that  depend  on  the  number  of 
states  on  the  path  that  satisfy  a  given  condition.  For  example,  we  may  wish  to  determine 
the  minimum  or  maximum  number  of  times  a  condition  cond  holds  on  any  path  from  start 
to  final  The  algorithm  in  this  section  compute  this  information. 
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To  simplify  the  algorithms,  we  assume  that  any  path  beginning  in  start  must  reach  a  state 
in  final  in  a  finite  number  of  steps.  This  requirement  is  necessary  to  ensure  that  the  mini¬ 
mum  (maximum)  is  well-defined.  It  can  be  checked  using  the  upper  bound  algorithm 
described  in  the  previous  section.  Finally,  we  assume  that  all  computations  involve  only 
reachable  states.  This  can  be  achieved  by  intersecting  start  with  the  set  of  reachable  states 
computed  a  priori. 

To  keep  track  at  each  step  of  the  number  of  states  in  cond  that  have  been  traversed,  we 
define  a  new  state-transition  system,  in  which  the  states  are  pairs  consisting  of  a  state  in 
the  original  system  and  a  positive  integer.  Thus,  if  the  original  state-transition  graph  has 
state  set  S,  then  the  augmented  state  set  will  be  5^  =  5  x  IN. 

If  iV  c  5  X  5  is  the  transition  relation  for  the  original  state-transition  graph,  we  define  the 
augmented  transition  relation 

Na({s,k},  {s', 10)  =  N(s,  s')  A  ((/  €  cond  a  =  k  +  1)  v  (/  €  cond  Ak'  =  k)) 

In  other  words,  there  will  be  a  transition  from  {s,K)  to  {s',k')  in  the  augmented  transition 
relation  iff  there  is  a  transition  from  s  to  /  in  the  original  transition  relation  N  and 
either  /  e  cond  and  kf  =  k+ lot  s'  ^  cond  and  k'  =  k.  We  also  define  to  be  the  function 
that  for  a  given  set  returns  the  set  of  successors  of  all  states  in  U.  More  formally, 

TJ^U)  =  {«'  I  Ng(u,  u)  holds  for  some  ue  I/}.  In  the  actual  BDD-based  implementation, 
an  initial  bound  k^^  can  be  selected  to  achieve  a  finite  representation  for  k,  and  new  BDD 
variables  can  be  added  dynamically  if  this  bound  is  exceeded.  The  system  is  still  finite- 
state  because  all  paths  we  consider  are  finite  and  k  is  bounded  by  their  maximum  length. 

5.3.1  Minimum  Condition  Counting 

The  algorithm  for  computing  the  minimum  count  is  given  in  figure  20.  In  the  algorithm 
text,  final  and  not_final  denote  the  sets  of  states  in  final  and  S  -final,  paired  with  all  possi¬ 
ble  values  of  k.  More  formally: 
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final  =  {(s,k)  1 5  e  final,  it  e  IN}  and  notjinal  =  {(s,k)  1 5  €  final,  ^:  €  IN} 

The  algorithm  uses  R  to  represent  the  state  set  in  Sa  reached  at  the  current  iteration,  while 
reached Jinal  and  K  are  its  intersections  with  final  and  notjinal  respectively.  Variable 
current_min  denotes  the  minimum  count  for  all  previous  iterations.  The  minimum  compu¬ 
tation  over  the  set  of  values  of  k  can  be  done  by  quantifying  out  the  state  variables  and  fol¬ 
lowing  the  leftmost  nonzero  branch  in  the  resulting  BDD,  provided  it  uses  an  appropriate 
variable  ordering.  An  efficient  algorithm  that  does  not  depend  on  the  variable  ordering  is 
given  in  [58]. 

proc  mincount  {start,  cond,  final) 
currentjnin  = 

i?  =  1  .s  e  start  n  cond  }  u  {<^,0>  I  s  e  start  n  -,cond}; 

while  true  do 

reachedjinal  =  Rr^  final, 
if  reachedjinal  ^  0  then 

m  =  min  (it  I  {s,k)  e  reachedjinal]', 
if  m  <  currentjnin  then  currentjnin  =  m; 

R'  =  Rn  notjnal; 

if /?'  =  0  then  return  currentjnin', 

R  =  T{Ry, 

Figure  20.  Minimum  Condition  Count  Algorithm 

At  iteration  i,  the  algorithm  considers  the  endpoints  of  paths  with  i  states.  The  reached 
states  that  belong  to  final  are  terminal  states  on  paths  that  we  need  to  consider.  The  mini¬ 
mum  count  for  these  paths  is  computed,  using  the  counter  component  of  the  path  end¬ 
points,  and  the  current  value  of  the  minimum  is  updated  if  necessary.  For  the  reached 
states  that  do  not  belong  to  final,  we  continue  the  loop  after  computing  their  successors.  If 
all  reached  states  are  in  final,  there  are  no  further  paths  to  consider  and  the  algorithm 
returns  the  computed  minimum.  Figure  21  shows  how  both  the  minimum  and  the  maxi- 
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mum  algorithm  work.  In  the  figure,  black  states  satisfy  cond.  The  current  frontier  (the 
shaded  area)  is  expanded  forward,  while  the  counter  component  maintains  the  number  of 
occurrences  of  cond  on  paths  from  S.  In  the  figure,  darker  areas  have  higher  counts,  and 
the  last  iteration  shows  a  minimum  count  and  a  maximum  count  paths. 


0: 


1: 


2: 


3: 


Figure  21.  Condition  counting:  the  condition  counter  is  updated  during  traversal. 

We  reason  about  the  correctness  of  the  algorithm  by  showing  that  the  following  invariants 

are  true  before  the  i*  iteration  of  the  loop: 

•  A  pair  {s,k)  belongs  to  Z?  iff  ^  can  be  reached  from  start  on  a  path  with  i  states,  on 
which  k  states  are  in  cond,  and  only  the  last  state  is  allowed  to  be 'm  final. 

•  l2-  current_min  is  the  minimum  number  of  states  in  cond  over  all  paths  with  less  than  i 
states  that  begin  in  start  and  terminate  upon  reaching  final,  or  infinity  if  there  are  no 
such  paths. 
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Initially,  R  is  the  set  of  states  in  start,  paired  with  1  if  they  belong  to  cond  and  with  0  oth¬ 
erwise,  and  currentjnin  is  «>.  Therefore,  both  invariants  hold  before  the  first  iteration. 

By  invariant  /j,  the  intersection  reached_final  =  R  final  contains  all  states  in  final 
reached  for  the  first  time  by  a  path  containing  i  states.  The  count  component  ^  of  a  reached 
state  is,  by  /j,  the  number  of  states  in  cond  on  such  a  path.  Computing  the  minimum  m  of 
these  values  and  setting  currentjnin  =  w  if  m  is  smaller  ensures  that  current_min  accounts 
for  paths  with  up  to  i  states.  Therefore,  I2  holds  at  the  beginning  of  the  next  iteration. 

Since  we  only  consider  paths  that  reach  final  once,  it  is  correct  to  continue  the  state  tra¬ 
versal  only  from  states  in  /?'  =  /?  n  notjinal.  If  this  set  is  empty,  there  are  no  further  paths, 
with  more  that  i  states,  that  reach  ^naZ.  Therefore,  by  invariant  I2,  current_min  is  the  cor¬ 
rect  return  value.  For  the  case  where  the  loop  is  continued,  the  definition  of  transition  rela¬ 
tion  ensures  that  the  count  component  in  the  augmented  state  space  is  incremented  on  a 
transition  step  if  and  only  if  the  new  state  is  in  cond.  This  implies  that  the  count  compo¬ 
nent  k  represents  at  all  times  the  number  of  states  in  cond  traversed  on  a  path.  Conse¬ 
quently,  Zj  will  hold  again  for  the  new  value  of  R  obtained  as  the  image  of  R'  under  T. 

Next,  we  argue  that  the  algorithm  terminates.  The  precondition  ensures  that  all  paths  from 
start  reach  final  in  a  finite  number  of  steps.  Thus,  we  will  eventually  have  R'  =  R  r\ 
notjinal  =  0,  and  the  algorithm  correctly  returns  the  value  currentjnin. 

As  an  optimization,  the  number  of  iterations  required  in  certain  cases  can  be  reduced  by 
introducing  the  line 

R'  =  R'  n  {(s,k}  1 5  6  S  A  k<  currentjnin) 

before  testing  R'  =  0.  All  paths  with  a  count  of  at  least  currentjnin  can  be  safely  dis¬ 
carded,  which  reduces  the  search  to  those  paths  on  which  the  count  for  cond  is  still  smaller 
than  the  currently  achieved  minimum. 
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5.3.2  Maximum  Condition  Counting 

The  algorithm  for  the  maximum  count,  given  below,  has  the  same  structure  as  the  mini¬ 
mum  count  and  can  be  obtained  by  replacing  min  with  max  and  reversing  the  inequalities. 
Variants  of  both  algorithms  can  be  used  to  compute  other  measures  that  are  a  function  of 
the  number  of  states  on  a  path  that  satisfy  a  given  condition.  For  example,  we  can  deter¬ 
mine  the  minimum  and  the  maximum  number  of  states  belonging  to  a  given  set  cond  over 
all  paths  of  a  certain  length  I  in  the  state  space. 

proc  maxcount  (start,  cond,  final) 
current_max  -  -«>; 

R  =  {<5,1)  I  s  €  start  n  cond}  u  {<5,0)  I  5  e  start  n  -tcond}; 

loop 

reached_final  =  R  n  final; 
if  reached_final  ^  0  then 

m  =  max{A:  I  {s,k)  e  reachedjinal}; 

if  m  >  currentjnax  then  currentjrmx  =  m; 

R'  =  Rn  not_final; 

if  /?'  =  0  then  return  currentjnax; 

R  =  TiR'); 
endloop; 


Figure  22.  Maximum  Condition  Count  Algorithm 


5.4  Quantitative  Analysis:  Optimized  Condition  Counting 

The  condition  counting  algorithms  presented  in  the  previous  section  augment  the  state 
space  with  a  counter  k.  This  counter  maintains  information  about  the  number  of  times  the 
condition  cond  has  been  encountered  on  paths  from  start.  The  algorithm  actually  com¬ 
putes  all  possible  values  of  k  for  all  paths  beginning  in  start.  Algorithms  requiring  the 
exact  number  of  times  cond  occurs  can  be  constmcted  from  the  basic  condition  counting 
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algorithms.  However,  for  the  computation  of  the  minimum  and  maximum  the  exact  num- 
ber  of  occurrences  is  not  needed.  The  algorithms  presented  in  this  section  can  be  used  to 
count  minimum  and  maximum  occurrence  times  without  augmenting  the  state  space. 

5.4.1  Optimized  Minimum  Condition  Counting 

The  minimum  condition  count  algorithm  computes  the  minimum  number  of  states  satisfy¬ 
ing  a  given  condition  cond  over  all  paths  that  start  in  a  state  in  start  and  end  in  a  state  in 
final.  Any  paths  starting  in  start,  but  which  do  not  reach  final  in  a  finite  number  of  steps 
are  excluded  from  this  computation.  In  particular,  if  no  path  from  start  ever  reaches  final, 
the  algorithm  will  return  the  special  value  NOPATH. 

The  algorithm  searches  forward  beginning  in  start.  It  looks  for  paths  with  an  increasing 
number  of  occurrences  of  cond.  Each  iteration  consists  of  two  phases:  The  first  is  a  for¬ 
ward  traversal  through  states  that  do  not  satisfy  cond.  This  traversal  is  performed  until  all 
states  (not  satisfying  cond)  reachable  from  the  current  frontier  are  found  (steps  1  and  3  in 
figure  24).  If  final  has  not  been  reached  yet,  the  frontier  is  expanded  by  one  step  to  states 
that  satisfy  cond  and  the  condition  counter  is  incremented  (steps  2  and  4  below).  The  algo¬ 
rithm  iterates  -mill  final  is  found,  or  all  reachable  states  are  visited. 

The  algorithm  must  differentiate  between  states  that  do  not  satisfy  cond  and  those  that  do, 
and  similarly,  between  transitions  leading  to  these  states.  We  use  subscripts  0  and  1 
respectively  for  the  two  types  of  states  and  transitions.  For  example,  starts  is  the  set  of  ini¬ 
tial  states  that  do  not  satisfy  cond,  and  starts  is  the  set  of  initial  states  that  satisfy  cond. 

startQ  =  start  o  —\Cond  start ^  =  start  D  cond 

Furthermore,  if  N{s,  s')  is  the  transition  relation,  we  denote  by  Tq{S)  and  TjfS)  the  set  of 
transitions  from  a  state  in  5  that  lead  to  states  not  satisfying  cond  and  to  states  satisfying 
cond,  respectively: 

Tq{S)  =  {5'  I  3  5  e  S  .  N(s,s')  as'  i  cond} 

Ti(S)  =  {/ 1  3  5 e  S .  N(s,s')  as'  e  cond} 
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proc  mincount(stzxt,  cond,  final) 

1  =  0; 

R  =  0; 

R'  =  startQ, 

do 

do 

if  (/?'  n  final  ^  0)  return  i; 

R  =  R'; 

R'  =  ToiR')uR'-, 

while  (/?' jR); 

R'  =  T^{R')kjR'; 

if  (i  =  0)  /?'  =  /?'  u  start  i, 

/  =  i  +  1 ; 
while 

return  NOPATH; 

Figure  23.  Minimum  Condition  Count  Algorithm 

We  will  prove  the  correctness  of  the  algorithm  by  showing  that  certain  loop  invariants  are 
satisfied  and  that  the  algorithm  terminates.  We  will  use  the  following  notations: 

•  endpoints{i)  is  the  set  of  all  states  that  can  be  reached  as  endpoints  of  finite  paths  start¬ 
ing  in  start  and  having  i  or  less  states  in  which  cond  holds. 

•  mincount  is  the  minimum  condition  count  as  described  above. 

Two  invariants  are  defined.  The  first  holds  at  the  start  of  iteration  z  +  1  of  the  outer  loop: 
/j(/):  ((i  =  0  aR'  =  startQ)  v  (z  >  0  a  i?'  =  endpoints{i)  r>  cond))  a  mincount  >  i 

The  second  holds,  in  the  same  iteration,  after  the  inner  loop: 

/2(z):  R'  =  endpoints{i)  a  R'  n  final  =  0  a  mincount  >  i 
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Figure  24.  Optimized  minimum  count:  each  iteration  has  two  steps:  1  and  2;  3  and  4. 
Lemma  1  The  algorithm  terminates. 

Proof  If  a  state  satisfying  is  reached,  the  algorithm  clearly  terminates,  returning  the 
current  value  of  i.  If  not,  the  exit  condition  of  both  loops  is  R'  =  R.  By  construction  R  "^R, 
and  since  there  is  only  a  finite  number  of  states,  there  can  be  no  infinite  sequence  of  dis¬ 
tinct  values  for  R'. 

Lemma  2  /j  and  I2  are  invariants  of  the  algorithm. 

Proof  The  correctness  of  the  invariants  will  be  proven  by  induction  on  i.  Invariant  /i(0) 
clearly  holds  at  the  beginning  of  the  first  outer  loop,  since  i  =  0,  /?'  =  startQ,  and  mincount 
>  0.  We  will  now  prove  that  /i(0  — >  and  12(1)  — >  /i(i+l)- 


104 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


Quantitative  Analysis:  Optimized  Condition  Counting 

Assume  /j  holds  at  the  beginning  of  iteration  i.  If  i  -  0,  we  have  B!  =  startQ  before  the 
inner  loop.  If  the  control  flow  exits  the  inner  loop,  a  fixpoint  has  been  reached.  R'  will  con¬ 
tain  all  states  reachable  from  start  on  paths  where  cond  does  not  hold  (because  of  the 
restriction  on  Tq).  But  this  is  exactly  endpoints(0),  by  definition,  so  /2(0)  holds.  If  i  >  0, 
then  by  we  have  R'  =  endpoints{i)  n  cond  before  the  inner  loop.  A  state  s  is  in  end- 
points(i)  n  -^cond  iff  there  is  a  state  t  e  endpoints(0  n  cond  from  which  s  is  reachable  by 
a  path  that  does  not  pass  again  through  cond.  The  inner  loop  adds  precisely  the  set  of  all 
such  states  to  /?'.  Therefore,  after  the  inner  loop  R'  =  endpoints(i).  Moreover,  R'  r\  final  = 
0,  otherwise  the  algorithm  would  have  terminated  in  the  inner  loop.  We  conclude  that 

/l(0^/2(0. 

Now  assume  Iiii)  is  true  at  the  end  of  the  inner  loop,  and  let  us  prove  that  /i(i+l)  holds  at 
the  beginning  of  the  next  outer  loop  iteration.  A  state  s  e  endpoints{i+\)  n  cond  satisfies 
one  of  two  cases:  It  is  either  on  a  nondegenerate  path  from  start,  and  thus  reachable  by  a 
transition  from  a  state  in  endpoints{i),  or  it  is  on  a  degenerate  path  from  start  (i  =  0  and  j 
e  start]).  In  the  first  case,  it  is  added  to  R'  in  the  first  statement  after  the  inner  loop,  and  in 
the  second  case,  in  the  second  statement  after  the  inner  loop.  Therefore,  after  line  11,  R'  = 
endpoints{i->r\)  n  cond.  Furthermore,  since  the  inner  loop  was  exited  with  R'  =  end- 
pointsii)  n  final  by  ^(i),  there  is  no  path  with  count  <  i  that  reaches  final,  so  mincount  >  i 
or,  equivalently  mincount  +  1.  Taking  into  account  that  i  is  incremented  in  line  13,  both 
conjuncts  of  Ii(i+l)  are  satisfied,  which  shows  that  72(0  -»  /i(i+l).  The  induction  proof  is 

completed. 

Lemma  3  The  algorithm  returns  the  minimum  number  of  occurrences  of  cond  in  any  path 
from  start  to  final. 

Proof  The  correctness  of  the  algorithm  can  be  seen  by  analyzing  its  return  value.  There 
are  two  possible  return  conditions,  the  first  being  when  R'  r\  final  0  and  the  algorithm 
returns  i.  At  this  point  R!  c  endpoints(i)  by  I]  and  the  restriction  on  Tq.  Consider  a  state  s 
e  R'  r\  final.  Then  5  g  endpoints{i-\)  since  /2(i-l)  ensured  that  endpoints{i-\)  n  final  =  0. 
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Therefore  s  must  be  reached  by  a  path  containing  exactly  i  states  satisfying  cond  and  thus 
mincount  <  i.  Since  by  /j  mincount  >  i,  we  conclude  that  mincount  =  i. 

If  the  algorithm  returns  NOPATH,  then  R'  doesn’t  intersect in  any  iteration.  The  algo¬ 
rithm  exits  the  outer  loop  when  R  =  R',  which  means  that  a  fixpoint  has  been  found.  Every 
state  reachable  from  start  can  be  found  by  alternating  (possibly  empty)  sequences  of  tran¬ 
sitions  in  Tq  with  transitions  in  Jj.  Therefore  that  fixpoint  is  precisely  the  set  of  states 
reachable  from  start.  We  can  conclude  that  all  paths  originating  in  start  will  be  completely 
contained  in  -final,  since  R'  n  final  =  0.  Hence,  the  algorithm  returns  the  correct  value 
NOPATH. 

5.4.2  Optimized  Maximum  Condition  Counting 

The  maximum  condition  count  algorithm  computes  the  maximum  number  of  states  satis¬ 
fying  a  given  condition  cond  over  all  paths  that  begin  in  a  state  in  start  and  end  in  a  state  in 
final  without  previously  traversing  a  state  in  final.  If  there  is  a  path  beginning  in  start  that 
goes  through  cond  infinitely  often  without  reaching  final,  the  algorithm  returns  infinity. 
The  basic  idea  behind  the  algorithm  is  to  find  paths  with  increasing  condition  count  whose 
states  are  all  within  —final.  The  condition  count  of  the  longest  path  satisfying  this  condi¬ 
tion  and  starting  in  start  is  the  desired  maximum. 

The  algorithm  assumes  that  all  states  are  reachable  from  start.  This  can  be  enforced  by 
performing  a  reachability  computation  from  start  and  restricting  the  state  space  to  reach¬ 
able  states.  Moreover,  we  require  that  every  state  has  at  least  one  outgoing  transition. 

Similarly  to  the  mincount  algorithm,  we  will  denote  transitions  into  states  that  satisfy  cond 
and  that  do  not  satisfy  cond  separately.  This  algorithm,  however,  performs  a  backward 
search,  and  we  must  define  the  reverse  image  of  the  transition  relation.  In  this  case  Bq{S') 
is  the  set  of  states  satisfying  neither  cond  nor  final  that  lead  to  a  state  in  S'  in  one  step. 
Similarly  jBiCS')  is  the  set  of  states  satisfying  cond  but  —final  that  lead  to  a  state  in  S'  in 
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one  step.  Note  thal  final  only  appears  implicitly  in  the  algorithm,  in  the  definitions  of  Bq 
and5i. 

Bq{S')  =  {s  \3  s' ^  s'  .  N(s,  s')  AS  i  final  as  i  cond] 

Elis')  =  {j  1 3  /  €  5' .  Nis,  s')  A  si.  final  Ase  cond) 

We  use  the  following  notations: 

.  startpointsii)  is  the  set  of  all  states  that  are  the  start  of  a  finite  path  in  which  has  no 
states  in  final  (except  possibly  the  last  one),  and  which  has  i  states  that  belong  to  cond. 

•  maxcount  is  the  maximum  condition  count,  for  a  path  starting  in  start  and  ending  in 
cond,  in  which  no  states  belong  io  final,  except  possibly  for  the  last  one  belong  to  final. 

proc  maxcountistart,  cond,  final) 

1=1; 

R'  =  cond; 

do 

Ri  =  R'; 

do 

R  =  R'; 

R' =  R' u  BoiR'); 
while  (R'^R)  ; 

if  (R'  n  start  =  0)  return  i  - 1 ; 

R'^BiiR'y, 
i  —  i+  1 ; 

while 
return  <»; 

Figure  25.  Maximum  Condition  Count  Algorithm 
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We  prove  the  correctness  of  the  algorithm  using  two  invariants.  The  first  one  holds  at  the 
beginning  of  the  outer  loop: 

/}(/):  R'  =  startpoints(i)  n  cond  a  /  - 1  <  maxcount 

The  second  invariant  holds  at  the  end  of  the  inner  loop: 

12(1)'.  R'  =  startpointsii)  a  i  -  1  <  maxcount 

Lemma  4  /]  and  I2  are  invariants  of  the  algorithm. 

Proof  We  prove  by  induction  on  i  that  the  invariants  hold  at  the  corresponding  points  in 
the  algorithm  and  argue  separately  about  termination.  Invariant  /i(0)  trivially  holds  at  the 
beginning  of  the  first  iteration,  since  paths  with  a  condition  count  of  1  that  have  both  end¬ 
points  in  cond  are  exactly  the  degenerate  paths  consisting  of  a  state  in  cond.  Furthermore, 
clearly  maxcount  >  0.  Next,  we  prove  that  /i(i)  — >  /2(0  and  that  72(1)  — >  7i(i+l). 

Assume  that  7i(i)  holds.  The  inner  loop  adds  to  R'  all  states  that  lead  to  states  in  R^,  with¬ 
out  being  in  final  or  cond.  Since  all  states  in  startpointsii)  can  be  found  by  a  backward  tra¬ 
versal  from  startpointsii)  a  cond  and  i  does  not  change,  this  establishes  /2(0- 

Now  assume  /2(i)  holds  after  the  inner  loop,  and  that  R'  n  start  ^  0  (otherwise  the  algo¬ 
rithm  terminates  and  we  have  no  further  invariants  to  prove).  Then  there  is  at  least  one 
path  from  start  to  cond  with  i  occurrences  of  cond,  and  therefore  maxcond  >  i.  A  state  p  is 
in  startpointsii+l)  n  cond  exactly  if  it  belongs  to  cond  and  it  has  some  successor  in  start¬ 
pointsii).  Therefore,  since  R'  =  startpointsii)  by  l2ii),  we  will  have  B^iR')  -  start¬ 
pointsii+l)  n  cond,  thus  i  -  I  <  maxcond  after  i  is  incremented,  and  /i(i+l)  holds,  which 
completes  our  induction  proof. 

Lemma  5  The  algorithm  terminates. 
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Proof  The  inner  loop  of  the  algorithm  performs  a  backward  reachability  computation.  It  is 
executed  only  a  finite  number  of  times,  because  the  value  of  R'  is  monotonically  increas¬ 
ing,  and  the  state  space  is  finite,  so  a  fixpoint  has  to  be  reached.  Next,  we  argue  that  the 
outer  loop  finishes  as  well.  This  clearly  happens  if  at  some  point,  R'  n  start  =  0  after  the 
inner  loop.  Otherwise,  let  us  show  that  the  sequence  of  values  R'  at  the  end  of  each  outer 
loop  iteration  is  monotonically  decreasing.  By  Ii,R'  =  startpoints{i)  n  cond.  But  any  state 
in  startpoints{i)  is  certainly  in  startpoints{i-\),  since  we  can  restrict  the  path  with  i  occur¬ 
rences  of  cond  to  some  prefix  containing  only  i  - 1  states  in  cond.  Since  the  state  space  is 
finite,  the  monotonically  decreasing  sequence  of  sets  R'  will  eventually  reach  a  fixpoint, 
the  loop  terminates  and  the  execution  of  the  algorithm  as  well. 

Lemma  6  The  algorithm  returns  the  maximum  number  of  occurrences  of  cond  in  any  path 
from  start  to  final. 

Proof  If  R'  n  start  =  0  at  the  end  of  the  inner  loop,  this  means  that  there  are  no  paths  with 
count  i  leading  from  start  to  cond,  completely  in  -final,  and  consequently,  no  paths  with 
count  greater  than  i  (since  they  would  have  a  prefix  with  count  i).  Therefore,  maxcount  <  i. 
Since  by  I2,  maxcount  >  /  - 1,  it  follows  that  maxcount  =  i  - 1  is  the  correct  return  value.  If 
the  outer  loop  is  exited  due  to  the  fixpoint,  startpointsii)  =  startpoints(i+j)  for  all  j  >  0. 
Moreover,  startpoints{i)  n  start  ^  0,  therefore,  there  exists  an  infinite  path  beginning  in 
start,  completely  contained  in  -final  and  in  which  cond  holds  infinitely  often. 


5.5  Selective  Quantitative  Analysis  and 
Interval  Model  Checking 

Typically,  quantitative  analysis  investigates  all  intervals  between  a  set  of  initial  states  start 
and  a  set  of  final  states  final.  In  many  cases,  however,  it  is  desirable  to  restrict  the  consid¬ 
eration  to  only  execution  paths  that  satisfy  a  certain  condition.  This  can  help  in  under¬ 
standing  how  the  system  reacts  to  different  conditions.  For  example,  one  common 
technique  for  achieving  good  performance  is  to  optimize  a  design  for  the  most  common 
cases,  while  maintaining  correcmess  for  the  uncommon  ones.  The  designer  can  optimize 
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response  time  by  restricting  system  behavior  to  the  most  frequent  cases.  Correctness  can 
then  be  checked  by  removing  the  restrictions.  This  section  presents  algorithms  that  allow 
the  designer  to  perform  quantitative  analysis  very  accurately  by  selecting  execution 
sequences  of  interest  and  analyzing  them  separately. 

Formulas  of  the  linear-time  temporal  logic  LTL  are  used  to  specify  a  set  of  paths  selected 
to  be  verified.  Quantitative  analysis  is  then  applied  only  to  those  paths  along  which  the 
formula  holds.  We  also  extend  the  technique  for  cases  in  which  a  more  precise  analysis  is 
needed,  by  requiring  that  the  selecting  formula  be  true  exactly  on  the  investigated  interval 
and  not  just  anywhere  on  the  path. 

To  strengthen  our  verification  methodology,  we  combine  selective  quantitative  analysis 
with  model  checking.  Traditionally,  LTL  model  checking  procedures  [22,56,74]  accept  a 
structure  that  models  the  system,  a  set  of  initial  states,  and  an  LTL  formula.  The  proce¬ 
dures  determine  whether  the  formula  holds  on  all  infinite  paths  of  the  structure  starting  on 
some  initial  state.  In  this  work  we  extend  the  construction  of  [22]  for  interval  model 
checking,  that  is,  checking  a  formula  with  respect  to  finite  intervals. 

Both  interval  model  checking  and  selective  quantitative  analysis  can  be  used  to  extract 
information  related  to  specific  “parts”  of  a  system  without  changing  the  model.  Similar 
information  sometimes  can  be  obtained  by  restricting  the  model  to  disable  uninteresting 
behaviors,  or  by  marking  the  interesting  ones  using  observer  modules.  However,  these 
techniques  frequently  modify  system  behavior,  and  consequently  properties  are  checked 
on  a  model  different  than  the  original  one,  possibly  hiding  important  errors,  or  introducing 
false  ones.  Also,  such  methods  are  usually  ad  hoc,  the  class  of  execution  sequences  that 
can  be  analyzed  cannot  be  characterized  in  a  straightforward  way.  They  are  also  more  dif¬ 
ficult  to  implement  and  error-prone. 

Moreover,  the  fact  that  properties  are  verified  over  finite  intervals,  allows  very  different 
types  of  properties  to  be  expressed.  It  is  possible  to  check  for  “traditional”  properties  such 
as  safety  and  liveness,  but  also  to  investigate  system  behavior  in  more  detail.  In  the  real- 
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world  not  all  possible  execution  sequences  are  equally  interesting.  Nor  are  all  possible 
time  intervals  within  a  path. 

Linear-time  temporal  logics  interpreted  over  both  infinite  paths  and  finite  intervals  have 
been  introduced  in  [57,61].  However,  they  only  check  the  satisfiability  of  a  formula,  and 
do  not  handle  either  quantitative  analysis  or  interval  model  checking.  Interval  logics  are 
also  used  in  [67],  but  in  a  theorem  proving  context.  However,  what  differentiates  our 
method  from  related  ones  is  the  fact  that  these  tools  do  not  allow  a  selective  verification  of 
properties  as  the  proposed  method.  They  provide  no  natural  way  in  which  a  subset  of 
behaviors  can  be  analyzed  in  isolation,  not  allowing  as  rich  an  analysis  as  the  proposed 
method.  The  closest  method  to  our  selection  of  paths  or  intervals  is  the  use  of  fairness  con¬ 
straints  in  model  checking  [20,32,62].  However,  there  a  fairly  restricted  types  of  proper¬ 
ties  were  used  for  selection,  while  we  can  handle  any  LTL  formula.  Moreover,  only 
infinite  paths  can  be  selected  in  these  works. 

5.5.1  A  tableau  for  LTL 

Our  specification  language  is  a  linear-time  temporal  logic  called  LTL  [65].  The  logic  is 
used  for  two  different  purposes.  One  is  to  specify  a  property  of  the  system  that  needs  to  be 
verified.  The  other  is  to  specify  a  set  of  selected  paths  that  will  be  verified.  In  both  cases 
we  use  a  tableau  [56,74,22]  for  the  formula. 

We  first  give  the  syntax  of  LTL.  Given  a  set  of  atomic  propositions  AP,  LTL  is  defined 
inductively  as  follows.  Every  atomic  proposition  is  an  LTL  formula.  If/ and  g  are  LTL  for¬ 
mulas  then  -n/,  f  V  g,  X /and/U  g  are  also  LTL  formulas. 

The  semantics  of  LTL  is  defined  with  respect  to  a  labeled  state  transition  graph.  A  graph 
M  =  (5,  R,  L)  has  a  finite  set  of  states  S,  a  transition  relation  RaSxS,  and  a  labeling  func¬ 
tion  L :  S  PowersetiAP),  associating  with  each  state  the  set  of  atomic  propositions  true 
in  that  state. 
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An  infinite  sequence  jq.  ...  of  states  in  5  is  a  path  in  the  structure  M  from  a  state  5  iff 
5  =  5o  and  for  every  j  >  0,  (sj,  Sj+i)  e  R.  A  finite  sequence  [^q,  s^]  is  an  interval  in  a 

structure  M  from  a  state  j  iff  ^  every  0  <  n,  {sj,  -sy+i)  g  R-  An  interval  may 

be  a  prefix  of  either  a  finite  interval  or  an  infinite  path.  Thus,  may  or  may  not  have  suc¬ 
cessors  in  M.  The  size  of  interval  a  =  [^O’  •••’  denoted  |  a  1,  is  n.  &  is  defined  iff  0  <j  < 
n  and  it  denotes  the  suffix  of  a,  starting  at  sy 

For  a  formula/,  a  path  7t,  and  an  interval  a,  the  meaning  of  M,  7t  t=path/is  that/holds  along 
path  7t  in  the  graph  M.  M,  a  hm/means  that/holds  along  interval  a  in  M.  Given  a  desig¬ 
nated  set  of  initial  states  Sq,  we  say  that  M,  Sq  Npath/iff  for  every  path  Jt  from  every  state 
in  Sq,  M,  k  |=path  /•  Given  two  designated  sets  of  states  start  and  final,  we  say  that  M, 
[start,  final]  Knt/iff  for  every  interval  a  from  some  state  in  start  to  some  state  m  final, 
M,  s  l=int/  Note  that  this  definition  does  not  require  that  intervals  be  disjoint.  Unless  oth¬ 
erwise  stated,  overlapping  intervals  are  allowed. 

The  relation  l=path  is  defined  inductively  as  follows  (the  structure  M  is  omitted  whenever 
clear  from  the  context). 

1-  ^  Npath  />  iff  P  e  L{sq),  for  p  e  AP. 

2.  tt  |=pj{jj  — i/iff  7t  t^path/- 

3-  rr  hpath/i  '^fi  iff  ^  Npath/i  or  n  Npath/z- 

4.  tcf=pathX/i  iffjt  Npath/l‘ 

5.  7U  f=path/i  U/2  iff  there  exists  a  A:  >  0  such  that  t=path/2  and  for  all  0  <j  <  k,  tc'  t=path/i- 

The  relation  Knt  is  identical  to  l=path  for  atomic  propositions  and  boolean  connectives.  For 
temporal  operators  it  is  defined  by: 

6.  G  |=int  X/i  ifif  I  a  I  >  0  and  g^  t=int/i- 
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7.  <T  t=int/i  U/2  iff  there  exists  a  0  <  ^  <  n  such  that  a*  hnt/2  and  for  all  0  <;  <  ^,  &  hnt/l- 
The  following  abbreviations  are  used  in  writing  LTL  formulas: 

•  f  A  g  = V  — I  g) 

•  Yf^truelJf 

•  G/=-.F-./- 

In  the  following,  whenever  we  refer  to  a  path  that  satisfies  a  formula,  the  satisfaction  is 
with  respect  to  |=path-  Whenever  an  interval  is  considered  the  satisfaction  is  with  respect  to 
|=jnt.  Finally,  whenever  states  are  considered,  satisfaction  is  with  respect  to  |=  for  CTL,  as 
defined  in  section  2.1.1. 

Note  that,  in  the  definition  of  -  s^]  |=/we  do  not  consider  successors  of  s„  (whether 
they  exist  or  not).  This  definition  is  meant  to  capture  the  notion  of  an  interval  satisfying  a 
formula  independently  of  its  suffix;  satisfaction  is  always  defined  independently  of  the 
prefix. 

It  is  also  important  to  notice  that  LTL  formulas  may  have  quite  a  different  meaning  when 
interpreted  over  paths  or  over  intervals.  For  instance,  a  path  will  satisfy  the  formula  G  F  c 
iff  a  holds  infinitely  often  along  the  path.  On  the  other  hand,  an  interval  will  satisfy  this 
formula  iff  the  last  state  of  the  interval  satisfies  a.  Furthermore,  while  the  formulas  -i  X  a 
and  X  a  are  equivalent  over  paths;  these  formulas  are  not  equivalent  over  intervals.  To 
see  this,  consider  an  interval  [^q]  of  size  0.  [.sol  Knt  X  a  but  [sO]  X  —1  a. 

Let /be  an  LTL  formula.  We  construct  a  Kripke  structure  T(f),  called  the  tableau  for/, 
containing  all  paths  and  intervals  satisfying/.  The  tableau  described  below  is  based  on  the 
construction  given  in  [22].  There,  the  tableau  is  used  to  check  the  truth  of  a  LTL  formula 
for  all  paths  of  a  given  Kripke  structure.  Here  it  will  be  used  for  three  purposes: 
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•  Selecting  the  set  of  paths  of  a  structure  that  satisfy /and  computing  minimum  and  max¬ 
imum  delays  over  those  paths; 

•  Selecting  the  set  of  intervals  of  a  structure  that  satisfy /  and  computing  minimum  and 
maximum  delays  over  those  intervals; 

•  Checking  that  a  specified  set  of  intervals  of  a  structure  satisfy/. 

We  first  introduce  the  notion  of  fairness  constraint,  needed  for  some  of  the  tableau  appli¬ 
cations.  A  fairness  constraint  for  a  structure  M  can  be  an  arbitrary  set  of  states  in  M,  usu¬ 
ally  described  by  a  formula  of  the  logic.  A  path  in  M  is  said  to  ht  fair  with  respect  to  a  set 
of  fairness  constraints  if  each  constraint  holds  infinitely  often  along  the  path. 

We  now  give  an  informal  description  of  the  tableau.  A  state  of  the  tableau  is  a  set  of  for¬ 
mulas,  intended  to  be  true  along  all  paths  in  the  tableau  that  start  with  that  state.  The  tran¬ 
sition  relation  of  the  tableau  guarantees  the  satisfaction  of  all  formulas  except  formulas  of 
the  form/U  g.  If/U  g  is  included  in  a  state,  then  the  tableau  construction  guarantees  that 
/is  true  as  long  as  g  is  not  true.  In  the  case  of  LTL  over  paths,  fairness  constraints  are 
required  in  order  to  identify  those  infinite  paths  along  which  g  will  eventually  be  true.  For 
LTL  over  finite  intervals,  it  is  sufficient  to  consider  those  intervals  that  have  a  final  state 
that  does  not  contain  any  formula  of  the  form  X  g.  Intuitively,  X  g  formulas  can  be  viewed 
as  transferring  to  next  states  the  requirements  that  are  necessary  for  the  satisfaction  of  / 
and  are  not  yet  fulfilled.  Thus  a  state  that  contains  no  formula  of  the  form  X  g  indicates 
that  all  necessary  requirements  have  already  been  fulfilled. 

The  tableau  T(f)  is  constructed  as  follows.  Let  APybe  the  set  of  atomic  propositions  in/. 
The  tableau  associated  with /is  a  structure  T(f)  =  (Sj,  Rt^  Lf)  with  APf&s  its  set  of  atomic 
propositions.  Each  state  in  the  tableau  is  a  set  of  elementary  formulas  obtained  from/.  The 
set  of  elementary  subformulas  of/is  denoted  by  el(f)  and  is  defined  recursively  by: 

•  elip)  ={p}  if  p  &  APf. 

.  el(-^f)  =  el(f). 
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•  el(fv  g)  =  el(f)'0  el(g). 

.  el(Xf)={Xf]uel(f). 

•  elifU  g)  =  {X(fV  g)}  u  el(f)  u  el(g). 

Thus,  the  set  of  states  Sj  of  the  tableau  is  Powerset{el(f)).  The  labeling  function  Lq-  is 
defined  so  that  each  state  is  labeled  by  the  set  of  atomic  propositions  contained  in  the  state. 

In  order  to  construct  the  transition  relation  Rj,  we  need  an  additional  function  sat  that 
associates  with  each  elementary  subformula  g  of/a  set  of  states  in  Sj.  Intuitively,  sat{g) 
will  be  the  set  of  states  that  satisfy  g. 

•  satig)  =  I  g  €  5  }  where  g  e  el(f). 

•  sat{-i  g)  =  {5 1 5  g  sat(g) } . 

•  sat{g  vh)  =  sat{g)  u  sat(h). 

•  sat{g  U  /i)  =  satQi)  u  {sat{g)  n  sat(X{g  U  h))). 

We  want  the  transition  relation  to  have  the  property  that  for  every  elementary  formula  X  g 
off,  X  g  is  in  a  state  iff  X  g  is  true  in  that  state.  Clearly,  if  X  g  is  in  some  state  5,  then  all 
the  successors  of  s  should  satisfy  g.  Moreover,  if  X  g  is  not  in  s,  then  no  successor  of  s 
should  satisfy  g.  Thus,  the  definition  for  Rf  is 

Rjis,  s')  =  Ax  ge  el(f)  e  satiX  g)  ^  s' e  satig)) 

Unfortunately,  the  definition  of  Rf  does  not  guarantee  that  eventuality  properties  are  ful¬ 
filled.  Consequently,  an  additional  condition  is  necessary  in  order  to  identify  those  paths 
and  intervals  along  which /holds.  In  order  to  identify  the  paths  along  which /holds  we 
define  a  set  of  fairness  constraints.  Fair  c  Powerset(Sj), 

Fairif)  =  {5ar(-i  (gV  h)v  h)\  gV  h  occurs  in/} 
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The  constructed  tableau  T(f)  includes  every  path  and  every  interval  which  satisfies/.  The 
following  theorem  characterizes  those  paths  and  intervals.  Notice  that  a  state  is  in  Power- 
set{APf)  iff  it  does  not  contain  any  formulas  of  type  X  g. 

Theorem  7  Let  T(f)  be  the  tableau  for/. 

1.  For  every  path  %  in  T(f),  if  n  starts  from  a  state  5  e  sat(f)  and  Jt  is  fair  for  Fairif)  then 
^(/)»  P  Hpath  /• 

2.  For  every  interval  ct  =  [to.  — .  t„]  in  T(f),  if  to  ^  sat(f)  and  t„  6  Powerset(AP^  then 
T(f),chntf- 

In  the  algorithms  presented  later  we  will  use  the  product  P  =  (Sp,  Rp  Lp)  of  Hf)  =  {Sj,  Rp 
Lq)  with  the  verified  structure  M  =  R^,  We  restrict  AP^to  be  a  subset  of  AP: 

•  Sp={(s,t)\sG  SM,t€  Sp  and  L^s)  n  APf=  Ljft) } 

•  Rp((s,  t'))  iff  Rm(.^,  s')  and  Rj{t,  t'). 

.  Lpi(s,t))  =  Lj{s). 

5.5.2  Selective  Quantitative  Analysis  Over  Paths 

Given  two  sets  of  states  start  and  final  in  M  and  an  LTL  formula/,  we  compute  the  lengths 
of  a  shortest  interval  and  a  longest  interval  from  a  state  in  start  to  a  state  in  final  along 
paths  from  start  that  satisfy/.  The  formula/is  interpreted  over  infinite  paths  and  is  used  to 
select  the  paths  over  which  the  computation  is  performed.  The  minimum  and  maximum 
algorithms  with  path  selection  are: 

1 .  Construct  the  tableau  for/,  T(j). 

2.  Construct  the  product  P  of  T(f)  and  M. 

3.  Use  model  checking  algorithms  on  P  to  identify  the  set  of  states /air  in  P,  where  a  state 
{s,  t)G  Sp(se  M,te  T(f))  is  in /air  iff  t  is  the  beginning  of  a  path  which  is  fair  with 

respect  to  Fair(f). 
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4.  Construct  P',  the  restriction  of  P  to  the  state  set  fair.  P'  =  {S'p,  R'p,  L'p)  is  defined  by: 
S'p  =fair,  R'p  =  Rpn  (S'p  x  S'p)  and  for  every  5  €  fair,  L'p{s)  =  Lpis). 

5.  Apply  minimum{st,  fn)  and  maximum{st,  fit,  notjh)  to  P' ,  with  st  =  {start  x  sat(f))  n 
fair,fn  =  {final  x  Sj)  n fair,  and  notjn  =fair  -fn. 

The  algorithms  work  correctly  because  P  contains  all  paths  of  M  that  are  also  paths  of  T(f) 
(the  proof  is  presented  in  section  5.5.5).  P'  is  restricted  to  the  fair  paths  of  T{f).  Thus, 
every  path  in  P'  from  {start  x  sat{f))  n  S'p  satisfies/.  Consequently,  applying  the  algo¬ 
rithms  to  P'  from  {start  x  sat{f))  n  S'p  to  (final  x  Sf)  n  S'p  over  states  in /air  produces  the 
desired  results. 

As  mentioned  before,  in  order  to  work  correctly,  the  algorithm  maximum  must  work  on  a 
structure  with  a  total  transition  relation.  The  transition  relation  of  P  is  not  necessarily  total. 
However,  the  transition  relation  of  P'  is  total  since  every  state  in /air  is  the  beginning  of 
some  infinite  (fair)  path. 

5.5.3  Selective  Quantitative  Analysis  Over  Intervals 

Given  two  sets  of  states  start  md  final  and  an  LTL  formula/,  we  compute  the  lengths  of  a 
shortest  and  a  longest  intervals  from  a  state  in  start  to  a  state  in  final  such  that/holds  along 
the  interval.  Here  the  formula/is  interpreted  over  intervals  and  we  consider  only  the  inter¬ 
vals  between  start  and  final  that  satisfy/. 

Modified  Quantitative  Algorithm 

Before  proceeding,  a  minor  modification  needed  in  the  maximum  delay  algorithm  is  pre¬ 
sented  below.  This  change  does  not  affect  the  correctness  of  the  algorithm,  but  is  neces¬ 
sary  in  order  to  allow  selective  quantitative  analysis  to  be  performed  over  intervals. 
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proc  max  {start,  final,  not_final) 

if  {start  n  {final  u  notjinal)  =  0)  then  return  oo; 

i  =  0; 

R  =  true; 

R'  =  notjinal, 

while  {R'  ^R  A  R'  r\  start ^  0)  do 
i  =  i+l; 

R  =  R'; 

R'  =  T^{R')  n  notjinal, 
if{R  =  R') 

then  return  OO* 
else  return  I, 

Figure  26.  Modified  Maximum  Delay  Algorithm 

The  only  changes  are  that  notjinal  is  now  a  parameter  of  the  algorithm,  and  an  initial  con¬ 
ditional  has  been  introduced.  Notice  that  if  notjnal  =  -i  final  the  modified  algorithm 
behaves  exactly  as  the  original  one.  The  only  case  in  which  notjnal  is  not  the  same  as 
—I  final  is  when  computing  properties  over  intervals.  As  will  be  seen  later,  in  this  case 
notjnal  correspond  to  states  not  in  final,  but  which  eventually  lead  to  final.  The  initial 
conditional  states  that  if  no  starting  state  is  in  final,  or  leads  to  final,  the  algorithm  returns 
infinity,  as  expected. 

We  will  use  a  special  formula  prop  to  identify  the  set  of  tableau  states  that  contain  only 
atomic  propositions. 

prop  =  { .r  e  1 5  e  Powerset{AP^  } 

The  formula  prop  is  a  set  of  states  in  T{f).  We  extend  prop  to  propp,  which  is  the  corre¬ 
sponding  set  of  states  in  P.  The  formula,  finalp  is  the  similar  extension  of  final: 
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propp  =  {(s,  t)  €  Sp\sG  Sm,  t €  prop} 
finalp  =  {is,t)e  Sp\se  final,  t  e  Sj} 

We  will  also  use  a  CTL  formula  x  to  identify  the  set  of  states  over  which  the  maximum 
algorithm  is  computed. 

X  =  -1  finalp  A  E[  -^finalp  U  {propp  a  finalp)  ] 

States  in  x  lead  to  states  that  are  endpoints  of  intervals  satisfying /(states  in  propp,  see 
theorem  7),  and  that  are  also  in  finalp.  The  requirement  that  finalp  does  not  hold  until 
propp  is  needed  because  an  interval  ending  in  finalp  without  going  through  propp  does  not 
satisfy  /. 

The  minimum  and  maximum  algorithms  with  interval  selection  are: 

1.  Construct  the  tableau  for/,  T(J). 

2.  Construct  the  product  P  of  T(f)  and  M. 

3.  Use  model  checking  algorithms  on  P  to  identify  the  set  of  states  that  satisfy  the  CTL 
formula  %. 

4.  Let  St  =  (start  x  sat(f))  n  Sp  and  let/i  =  (final  x  prop)  n  Sp.  The  algorithms  mini- 
mum(st,  fit)  and  maximum(st,  fit,  x)  when  applied  to  P  will  return  the  length  of  the 
shortest  and  longest  intervals,  respectively,  between  start  sxtd final  that  satisfy/. 

The  correctness  of  the  algorithm  relies  on  the  fact  that  P  contains  all  intervals  that  are  both 
in  T(f)  and  M.  Moreover,  intervals  of  Tif)  from  sat(j)  to  prop  satisfy/  Thus,  the  algorithms 
compute  shortest  and  longest  lengths  over  intervals  from  start  to  final  that  satisfy  /.  The 
proof  is  presented  in  section  5.5.5. 

When  the  maximum  algorithm  is  computed  over  the  set  notjinal  of  states  not  in  final,  it  is 
necessary  to  require  that  the  transition  relation  of  the  structure  is  total  in  order  to  guarantee 
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that  the  computed  intervals  terminate  at  a  state  in  final.  Here  the  maximum  algorithm  is 
computed  over  the  set  of  states  satisfying  the  formula  %.  This  guarantees  that  the  intervals 
considered  terminate  at  final  without  the  need  to  require  that  the  transition  relation  is  total. 

Selecting  Intervals  using  Formuia  Translation 

There  is  another  method  that  can  be  used  to  perform  selective  quantitative  analysis  over 
intervals.  Given  a  formula/ it  is  possible  to  translate  it  into  formula/  such  that/holds  on 
an  interval  n  =  -Sb  •••»  iff/  holds  on  paths  which  have  n  as  prefix.  For  example,  if 
/=  F  cond,  then/  =  start  final  U  cond).  It  is  possible  then  to  perform  selective  quan¬ 
titative  analysis  over  paths  on  formula/. 

However,  performing  the  analysis  over  paths  is  significantly  more  expensive  than  per¬ 
forming  it  over  intervals.  The  reason  is  that  checking  tableau  properties  over  infinite  paths 
require  verification  on  fair  paths,  and  computing  the  fairness  constraints  for  all  temporal 
operators  in  the  formula  is  very  expensive.  Tableau  properties  over  intervals,  on  the  other 
hand,  require  no  fairness,  since  intervals  are  finite. 

Intuitively  we  can  see  that  it  is  easier  to  determine  interval  satisfaction  because  it  does  not 
depend  on  the  interval  suffix,  and  as  soon  as  the  end  of  the  interval  is  identified,  verifica¬ 
tion  stops.  Path  satisfaction,  on  the  other  hand  must  be  guaranteed  for  infinite  paths,  and 
the  early  stop  condition  does  not  apply.  In  our  practical  experiments  using  formula  transla¬ 
tion  instead  of  verification  over  intervals  resulted  in  a  slow  down  of  about  5  to  6  times. 

5.5.4  Interval  Model  Checking 

For  a  given  a  structure  M  and  two  set  of  states  start  and  final,  an  interval  a  =  [^q,  ..., 
from  a  state  in  start  to  a  state  in  final  is  pure  iff  for  all  0<i<n,  s^  is  neither  in  start  nor  in 
final. 

Given  a  structure  M,  two  sets  of  states  start  and  final,  and  a  formula/,  the  interval  model 
checking  is  the  problem  of  checking  whether  the  formula/  interpreted  over  intervals,  is 
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true  of  all  pure  intervals  between  start  and  ^naZ  in  M.  An  interval  a  =  [5o, from  a 
state  in  start  to  a  state  in  final  is  pure  iff  for  all  0  <  i  <  n,  Si  is  neither  in  start  nor  in  final. 

Interval  model  checking  is  useful  in  verifying  periodic  behavior  of  a  system.  A  typical 
example  is  a  behavior  that  occurs  in  a  transaction  on  a  bus.  If  we  want  to  verify  that  a  cer¬ 
tain  sequence  of  events,  described  by  an  LTL  formula/,  occurs  during  a  transaction  we  can 
define  start  to  be  the  event  that  starts  the  transaction  and  final  to  be  the  event  that  termi¬ 
nates  the  transaction.  Interval  model  checking  will  verify  that  /  holds  on  all  intervals 
between  start  and  final. 

Let  M,  start,  final,  and /be  as  above.  The  algorithm  given  below  determines  the  interval 
model  checking  problem  using  the  minimum  delay  algorithm. 

1 .  Construct  the  tableau  for  -1/  r(-i  f). 

2.  Compute  the  product  P  of  T{—\j)  and  M. 

3.  Apply  the  algorithm  minimum(st,  fin)  to  P  with  st  =  {start  x  sat{—tf))  n  Sp  and  fn  = 
(final  X  prop)  n  Sp 

4.  If  the  minimum  is  infinity  then  there  is  no  pure  interval  from  start  io  final  that  satisfies 
— t/  Thus,  every  such  interval  satisfies/. 

5.5.5  Correctness  of  the  Algorithms 

Correctness  of  the  Tableau  Construction 

In  this  section  we  prove  the  properties  of  the  tableau,  as  stated  in  theorem  7.  There  are  two 
cases  to  consider,  for  infinite  paths  and  for  finite  intervals.  The  properties  of  the  tableau 
with  respect  to  infinite  paths  can  be  found  in  [22]  and  will  not  be  repeated  here.  In  this  sec¬ 
tion  we  prove  only  the  properties  related  to  finite  intervals. 
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Given  a  structure  M  and  a  tableau  T(f)  for/ e  LTL,  the  product  P  of  M  and  T(f)  is  a  struc¬ 
ture  in  which  the  intervals  from  sat{f)  to  prop  correspond  to  the  intervals  of  M  that  satisfy 
/.  In  fact,  intervals  in  the  product  have  a  closer  relation  with  intervals  in  M  and  7)- : 

Lemma  8 1"  =  a  path  or  an  interval  in  P  with  Lp{{si,t^)  =  Lq{t^  for  i  >  0 

iff  there  exist  T  =  5o,  —  in  M,  andx'  =  tQ,  t\, ...  in  T{f)  withL^^t,)  =  Lf^sj)  oAPyfor  /  >  0 


Proof  Immediate  from  the  definition  of  the  product. 

The  product  can  be  used  in  two  ways.  If  we  wish  to  restrict  our  attention  only  to  intervals 
in  M  from  start  io  final  that  satisfy/,  we  can  consider  instead  intervals  from  {start  x  sat{f)) 
to  (final  X  prop)  in  the  product  structure.  On  the  other  hand,  in  order  to  prove  that  all  inter¬ 
vals  from  start  to  final  in  M  satisfy  /,  we  construct  the  product  of  M  with  the  tableau  T{-if) 
of -if,  and  show  that  it  contains  no  interval  from  (start  x  sat{-yf))  to  (final  x  prop). 

Below,  we  state  more  precisely  the  properties  of  the  tableau  ensuring  that  the  product  has 
the  required  correspondence,  and  prove  their  correctness. 

In  order  to  identify  the  intervals  of  the  tableau  that  satisfy  /,  we  would  like  to  have  a 
lemma  of  the  form; 


{tv  -  y  Knt  /  iff  ti  e  sat(f)  A  r„  e  prop 

Unfortunately,  only  one  direction  of  this  statement  holds,  i.e.,  r,-  €  sat(f)  a  e  prop 
implies  that  [tf, ...  r„]  hnt  /» intervals  that  also  satisfy/. 

It  turns  out,  however,  that  the  intervals  from  sat(f)  to  prop  are  sufficient  in  the  sense  that 
for  every  structure  M.  and  every  interval  in  M.  that  satisfies/,  there  is  a  corresponding  inter¬ 
val  in  T(f)  that  starts  at  sat(f)  and  ends  in  prop.  Hence,  for  our  purposes  it  is  sufficient  to 
focus  solely  on  these  intervals. 
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Our  proof  is  structured  as  follows.  Theorem  11  proves  that  if  an  interval  in  the  tableau 
starts  in  a  state  that  satisfies  sat(f)  and  ends  in  a  state  in  prop  then  it  satisfies/.  Theorem  16 
proves  that  every  interval  in  M  that  satisfies /corresponds  to  an  interval  in  T(f)  that  starts 
in  sat(f)  and  ends  in  prop.  The  proof  uses  the  following  steps.  For  an  interval  [j,-, ...,  5„]  in 

M  we  define  a  sequence  [s],  ...  5^]  and  show  that  each  s*j  is  a  state  in  the  tableau 

d)(  ^ 

(Lemma  12).  We  notice  that  by  the  definition  of  sj,  the  last  element  in  the  sequence,  s^, 
contains  only  atomic  propositions  (Lemma  13).  Next,  we  show  that  [j,-,  ...,  5„]  [=jjjt/iff 
s*l  e  sat(f)  and  5*  e  prop  (Lemma  14).  Finally,  we  prove  that  there  is  a  transition  between 
s*  and  (Lemma  15),  thus  [j*,  ...,  j*]  is  an  interval  in  T(f).  Altogether  this  implies 
Theorem  16. 

We  start  with  Lemma  9  and  Lemma  10  that  prove  two  technical  results,  needed  in  later 
proofs.  These  results  help  to  relate  the  definition  of  satisfaction  1=  with  the  definition  of  the 
set  sat  for  formulas  of  the  form/U  g. 

Lemma  9  [5,-,  ...,5j  t=/U  g  iff  either  [si,  t=  g  or  [s,-,  ...,j'„]  l=/and  [5,-,  ...,^„]  |=  X(f  U  g). 

Proof  We  first  show  that  if  either  [5,-, ...,  ^  or  [^i,  •••»  -Sn]  1=/ and  [Sj, ...,  |=  X(fV  g), 

then  [si,  ...,5'„]  h/U  g,  i.e.,  there  exists  i<k<n  such  that  [5^,  f=  g  and  for  all  i  <j  <  k, 

[i^’,  ...,  iTjj]  ^ /. 

If  [5j, ...,  J„]  1=  g  the  result  immediately  holds  for  k  =  i.  Otherwise,  assume  [5,-, ...,  h/ 
and  [Si, ...,  Sn\  1=  X(/‘U  g).  The  latter  implies  that  j  <  n  and  that  ...,  s^]  N/U  g,  i.e., 
there  exists  /+!  <k<n  such  that  [sj^, ...,  5„]  1=  g  and  for  all  i+1  <j<k,  [5y, ...,  s„]  h/  In 
addition,  we  have  [si, ...,  .s„]  f=/  thus  we  get  the  required  result. 

For  the  other  direction,  let  [si, ...,  5„]  1=/U  g.  If  [5^^.,  ...,  i'n]  |=  g  for  A:  =  i  then  the  result 
immediately  holds.  Otherwise,  assume  that  there  is  i+l  <k<n  such  that  [5;^-  •••»  •^nl  N  8  and 
for  all  i<j<  k,  [sy, ...,  ^„]  |=/. 
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This  implies  in  particular  that,  [5,-, \=f.  It  also  implies  that  [Sj+j, t=/U  g.  Thus, 
[Si, ...,  s„]  1=  X(f  U  g),  as  required. 

Lemma  10 Let  [r,-, ...,  be  an  interval  in  T(f)  such  that  e  prop.  Let  gi  \]g2hta  subfor¬ 
mula  off.  Then,  r,-  g  sat(gi  U  g2)  iff  there  is  ai<k<n  such  that  g  satig2)  and  for  every 
i<j<k,tje  sat(gi). 

Proof  For  the  first  direction  assume  that  r,-  g  sat(gi  U  g2)-  We  prove  the  required  result  by 
induction  on  the  number  of  states  in  the  interval  [tj, ..., 

Basis:  Let  n=i,  i.e.,  g  sat(gi  U  g2).  If  t  satigi)  then  by  the  definition  of  sat{gi  U  gf), 
tf^  G  sat(K{gi  U  ^2))-  However,  g  prop,  thus  g  satigf)  and  the  claim  holds  for  k  =  i. 

Induction  step:  Assume  the  claim  holds  for  intervals  of  length  r.  Further  assume  that  r,  g 
satigi  U  g2)  for  an  interval  [f,-, ...,  r„]  of  length  r+1.  If  t,-  g  sat{g2)  then  we  are  done.  Other¬ 
wise,  if  G  satigf)  then  by  the  definition  of  sat{g\  U  gf),  ti  g  sat(gi)  and  ti  g  sat(K(gi  U 
g2)).  By  the  definition  of  Rj  we  have  that  ti+i  g  satigi  U  ^2)-  We  can  apply  the  induction 
hypothesis  on  the  interval  [tj+j, ...,  r„]  and  conclude  that  there  is  a  i+l  <  ^  <  n  such  that  g 
sat(g2)  and  for  every  i+l  <j<k,  tj  e  sat(gi).  Together  with  t,-  g  sat(gi)  this  implies  the 
required  result. 

For  the  other  direction  assume  that  there  is  a  i<k<n  such  that  g  sat{g2)  and  for  every 
i  <j  <  k,  tj  G  satfgi).  We  prove  that  t,-  g  sat{gi  U  g2)  by  induction  on  the  number  of  states 
in  the  interval  [r,-, ...,  t„]. 

Basis:  Let  n  =  i.  Then,  k  =  i  and  r,-  g  sat(g2)-  By  definition,  g  sat(gi  U  g2). 

Induction  step:  Assume  the  claim  holds  for  intervals  of  length  r  or  less.  Let  [t,-, ...,  tf\  be 
an  interval  of  length  r+1.  We  consider  two  cases.  If  k  =  i  then  ti  g  sat(g2),  and  conse¬ 
quently  ti  G  sat(gi  U  g2).  Otherwise,  if  *  >  /  then  t]^  g  sat{g2)  and  for  every  /+1  <j  <  k,  tj  g 
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sat(gi).  Thus,  the  induction  hypothesis  applied  to  the  interval  f„]  implies  that 

e  sat(gi  U  g2).  Since  (r,-,  t;+i)  €  Rf,  ti  e  sat(X(gi  U  ^2))-  But  also  t,-  e  satig^),  which 
implies  that  t,-  e  satig^  U  g2),  as  required. 

The  following  theorem  gives  a  characterization  of  the  intervals  in  T(f)  that  satisfy  a  given 
subformula  g  off. 

Theorem  11  Let  [r,-, be  an  interval  in  T(f)  and  let  €  prop,  then  for  every  subfor¬ 
mula  g  off, 

ti  e  sat(g)  iff  [tj, y  t=  g. 

Proof  We  prove  the  following  by  induction  on  the  structure  of  g: 
for  every  interval  [ti, y  such  that  e  prop, 

ti  e  sat{g)  iff  [ti, ...,  y  g. 


1 .  g  is  an  atomic  proposition. 

Then  ^  e  sat(g)  iff  g  e  Lj{t^.  By  definition  of  satisfaction,  this  holds  iff  [t,-, ...,  r„]  1=  g. 

2.  g  = 

ti  e  satig)  iff  ti  g  sat{g{).  By  the  induction  hypothesis,  this  holds  iff  [r,-, ...,  r„]  gi  iff 

[ti, ...,  y  g. 

3. g-Xgi. 

If  ti  e  sat(X  gi)  then  X  e  ti.  Thus  n  >  i  (otherwise  r„  g  prop)  and  ti  has  a  successor 
ti+i  in  the  interval.  Since  (t,-,  fj+i)  e  Rj,  ti+i  e  sflt(gi)  and  by  the  inductive  hypothesis, 
•••!  t/j]  H  ^1’  Thus,  [tj, ...,  y  ^  g. 

For  the  other  direction,  let  [tj,  ...,  y  |=  X  gj,  then  i  <  n  and  [tj+j,  ...,  r„]  |=  gj.  By  the 
inductive  hypothesis,  e  satigy).  Since  (r,-,  t/+i)  e  Rf,  ti  e  sat(X  gj). 

4.  g  =  gi  g2~  immediate. 
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5-  g  =  gi  U  g2- 

Let  ti  e  satigi  U  g2).  Since  €  prop,  then  by  Lemma  10,  there  is  a  i  <  fe  <  n  such  that 
e  sat{g2)  and  for  every  i<i<  k,  tj  e  sat{gi).  By  the  induction  hypothesis  we  have  that 
[th  •••’  y  N  S2  ^  -j  <  •••’  ^n\  t=  gi-  Thus,  [tj, r„]  N  gi  U  g2- 

For  the  other  direction,  assume  1=  gi  U  g2-  Then  there  exists  i<k<n  such  that 

[tk,  tn\  t=  82  and  for  all  i  <j  <  k,  [tj, rj  f=  gj.  By  the  induction  hypothesis,  e 
sat(g2)  and  for  all  i  <j  <  k,  tj  €  sat{g{). 

Since  we  also  have  that  e  prop.  Lemma  10  implies  that  r,-  e  sat{gi  U  g2). 

We  now  give  the  definitions  and  lemmas  needed  to  show  that  for  every  structure  M  and  for 
every  interval  in  M  that  satisfies/,  the  tableau  T(f)  contains  a  corresponding  interval  from 
sat(f)  to  prop  that  agrees  with  the  given  one  on  all  subformulas  of  /  To  do  so,  we  fix  an 
interval  [5o, ...,  in  a  structure  M  and  define,  for  every  0  <  i  <  n, 

s*i={g\g^  el(j)  and  [si, ..., 5„]  N g  } 

Lemma  12  For  every  0  <  i  <  n,  5*  is  a  state  in  T(f). 

Proof  This  is  clearly  the  case,  since  a  state  of  the  tableau  is  in  the  powerset  of  el(f). 
Lemma  13  s*^  e  prop. 

Proof  Note  that  X  g  e  iff  (by  the  definition  of  s*„)  [5*  ]  i=  X  g.  Since  an  interval  of  size 
zero  does  not  satisfy  a  formula  of  type  X  g,  X  g  g  5*  for  eveiy  X  g  €  el(f). 

Lemma  14  For  every  g  e  el(f)  u  sub(f),  where  subif)  is  the  set  of  all  subformulas  of/  and 
for  every  0  <  i  €  n, 

[Si, ...,  Sn\  Ng  iff  A  e  sat{g)  and  5*  e  prop. 
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Proof  We  prove  the  lemma  by  induction  on  the  structure  of  g,  where  all  elementary  for¬ 
mulas  are  considered  to  be  the  basis  for  induction. 

Basis:  g  e  el(f). 

For  the  first  direction,  assume  [5,-, s^]  |=  g.  Then,  by  the  definition  of  s*,  g  e  s]  and  by 
the  definition  of  satig),  s]  e  sat(g).  Since  5*  e  prop  always  holds  (by  lemma  13),  the 
proof  of  this  direction  is  completed. 

For  the  other  direction  assume  s*  e  sat{g)  and  5*  e  prop.  Then  by  the  definition  of  sat{g), 
g  &  Si  and  by  the  definition  of  s ,•  we  have,  [5^, ...,  .s„]  |=  g. 

Induction  step: 

1.  g  =  -^g\- 

Assume  [5,-,  ...,  1=  -1  gj.  Then,  [j,-,  ...,  5J  ^  gj.  By  the  induction  hypothesis  this 

implies  that  either  s*  g  sat{gi)  or  g  prop.  But  by  Lemma  13,  5*  e  prop  always 
holds.  Thus,  Si  g  sat{gx)  is  true,  and  therefore  Si  e  sat{->  gj). 

For  the  other  direction,  assume  s]  6  sat(->  gi)  and  s*„  e  prop.  Then,  g  sat{gi)  and 
therefore,  by  the  induction  hypothesis,  [si,  ...,  ^  gj.  Hence,  we  conclude  [j,-,  ..., 

2.  g  =  gi  V  g2  —  straightforward. 

3.  g  =  gi  U  g2. 

Assume  [si, ...,  s^]  t=  U  g2.  Then,  by  Lemma  9,  either  [si, ...,  5„]  |=  g2  or  [si, ...,  5„]  \= 
gj,  [j,-,  ...,  1=  X(gi  U  g2)  and  i  <  n.  By  the  induction  hypothesis  (the  induction 

hypothesis  also  applies  to  X(g]  U  g2),  since  it  is  an  elementary  formula,  and  therefore 
simpler  in  structure  than  (gj  U  g2)),  one  of  the  following  holds: 

•  sie  sat(g2)  and  s„g  prop,  or 
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•  s*  e  5af(gi)  n  sat(X(gi  U  g2)),  e  prop. 

■  By  the  definition  of  sat(gi  U  g2),  both  items  imply  that  s e  sat(gi  U  g2),  and  in  addi¬ 
tion  that  e  prop. 

For  the  other  direction,  assume  €  sai(gi  U  g2)  and  5*  e  prop.  By  the  definition  of 
sat(gi  U  g2)  one  of  the  following  holds: 

•  5 ;  e  sat(g2)  and  s*„  e  prop,  or 

•  s]  6  sat(gi)  and  s*  e  sat(X(gi  U  ^2))  and  e  prop. 

By  the  induction  hypothesis,  the  first  item  implies:  [5j,  ...,  5„]  [=  g2-  The  second  item 
implies:  [Si, ...,  5„]  ^=gi  and  [5,-, ...,  5„]  HX(gi  U  g2).  By  lemma  9  we  conclude  that  [5^, 
Sn\  l=gi  U  g2. 

Corollary  [jq,  ^„]  Kf  iff  e  sat(f)  and  5*  e  prop. 

It  is  also  important  to  prove  that  the  sequence  of  states  [j’*, ...,  s*^]  is  indeed  an  interval  in 
the  tableau. 

Lemma  15  For  every  0<i<n-l,(si,s  ,+i)  e  R^- 
ProofLetXge  el(f). 

•  €  sat(X  g)  iff  X  g  e  s],  by  the  definition  of  sat. 

•  iff  [Sf, ...,  5„]  t=X  g  by  the  definition  of  s*. 

•  iff  [%i, ...,  .sj  N  ^  by  satisfiability. 

•  iff  e  sat{g),  by  lemma  14,  since  5*  e  prop. 
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An  interval  [^q,  s^]  in  M  and  [tQ . rj  in  T(f)  correspond  iff  for  every  0<i<n,  L(si)  n 


Theorem  16  Let  M  be  a  structure  and  let  ^„]  be  an  interval  in  M  such  that  J 

1=/.  Then,  there  is  a  corresponding  interval  [tQ, ....  r„]  such  that  tQ  e  sat(f),  r„  6  prop  and 

[to,  y  N/- 

Proof  Given  an  interval  [^q,  -Sn]  in  a  structure  M,  we  choose  ti  =  5*.  By  Lemma  12  and 

Lemma  15  we  know  that  — >  -yn]  is  an  interval  in  T(f).  Since  [.so’  — » N/>  Lemma  14 
implies  that  tQ  e  sat(f)  and  f„  e  prop.  Clearly,  for  every  i,  1(5,)  r\APf=  Lj{t^.  Thus,  since 
[jQ, y  t=/,  [to,  -,  y  N/as  well. 

This  concludes  the  proof  of  correctness  of  the  tableau  construction. 

Correctness  of  the  Algorithms  with  Path  Selection 

We  now  show  that  the  minimum  and  maximum  algorithms  respectively  compute  the  mini¬ 
mum  and  maximum  lengths  of  all  intervals  in  M  from  start  to  final  on  paths  that  satisfy/. 

Lemma  17  For  every  path  7C  =  Jq*  —  in  M  such  that  n  |=/there  is  a  path  (59,  y,  (^i,  ti), 
...  in  P'  such  that  tQ  e  satif). 

Proof  This  lemma  is  a  consequence  of  theorem  1  in  [22]. 

Lemma  18  For  every  path  jc"  =  y,  (■si.  •••  in  Jt'  with  tQ  e  sat(f),  the  path  %  =  si, 

...  in  M  satisfies/. 

Proof  Let  7u"  =  y  >  (■^i,  h), ...  be  a  path  in  7t'.  Then,  every  state  on  7t"  is  in  fair.  Thus, 

7c'  =  ro>  h, ...  is  a  fair  path  in  T(f).  Since  it  also  starts  in  sat(f),  %'  ^/. 
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The  path  n  =  sq,  ...  in  M  agrees  with  7t'  on  the  atomic  propositions  in/.  Therefore,  n  t=/ 

as  well. 

Lemma  19  [Correctness  of  the  minimum  algorithm]  Let  st  =  (start  x  sat(f))  n  fair,  fit  = 

(final  X  Sf)  nfair  and  k  be  the  value  returned  by  minimum(st,fn)  applied  to  F. 

•  If  Jk  <  oo  then  k  is  the  size  of  a  shortest  interval  from  start  to  final  in  M,  along  a  path 
from  start  that  satisfies/. 

•  If  it  =  oo  then  there  is  no  interval  from  start  to  final  in  M  along  such  a  path. 

Proof 

•  Assume  that  minimum(st,fh)  returns  k  when  applied  to  P'.  Then  there  is  a  shortest  inter¬ 
val  [(^0’  ^o)>  •••’  in  P'  from  St  to  Jh. 

Since  (s^,  tf)  e  fn,  it  is  in  fair  as  well  and  therefore  it  is  the  start  of  a  path  (sj^,  tf),  (s^+i, 
4+1), ...  such  that  tf^,  t^+i, ...  is  a  fair  path  in  T(f).  Adding  a  prefix  to  a  fair  path  results  in 
a  fair  path.  Thus,  %'  =  tQ, ...,  tj^,  tj^+i, ...  is  also  fair.  Moreover,  it  starts  in  sat(f).  Thus,  by 
Theorem  7,  Ji'  satisfies  /. 

The  path  k  =  sq,  ...,  s^,  s^+i,  ...  in  M  agrees  with  %'  on  the  atomic  propositions  off 
Therefore,  if  satisfies/so  does  n.  Thus,  sf\  is  an  interval  of  size  *  from  start  to 
final  in  Af  on  a  path  that  satisfies/. 

•  Now  assume  there  is  a  shorter  interval  [mq,  ...»  «/]  with  I  <  k,  from  start  to  final  in  M 
along  a  path  U  =  uq,  mj,  ...  that  satisfies/  By  lemma  17,  there  is  a  path  U"  =  (uq,  vq), 
(ui,  vi), ...  in  n'  from  sat(f).  The  interval  [(mq,  vq),  ...,  (m/,  v/)]  starts  at  st,  ends  in  fh  and 
is  shorter  than  k.  This  contradicts  the  correctness  of  the  minimum  algorithm.  We  there¬ 
fore  conclude  that  A:  is  a  shortest  interval  in  M. 

•  Finally,  we  must  show  that  if  the  algorithm  returns  infinity  there  are  no  intervals  from 

start  to  final  on  paths  that  satisfy/.  Assume  there  is  one  interval  [^q,  fro®“  to 

final  along  a  path  jq.  -^1.  -  that  satisfies/  By  lemma  17,  there  is  a  path  (^o,  to)’  ^i)’ 
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...  in  n'  from  sat(f).  Consequently,  there  is  an  interval  [(^o»  ^o)*  •••’  ^  from 

(start  X  sat(f))  to  (final  x  Sj).  However,  this  contradicts  the  correctness  of  the  minimum 
algorithm.  We  therefore  conclude  that  no  interval  could  exist  in  this  case. 

Lemma  20  [Correctness  of  the  maximum  algorithm]  Let  st  =  (start  x  sat(f))  nfair,fii  = 
(final  X  Sf)  nfair  and  notjair  =fair  -fn.  Let  k  be  the  value  returned  by  maximum(st,  fit, 

not_final)  applied  to  P'. 

•  Ifk  <  oo  then  k  is  the  size  of  a  longest  interval  from  start  to  final  in  M,  along  a  path  from 
start  that  satisfies/. 

.  Ifk  ZZ  OO  then  there  is  no  bound  on  the  size  of  the  interval  from  start  to  final  in  M  along 
such  paths. 

Proof  The  proof  follows  the  same  reasoning  as  in  the  minimum  algorithm  and  will  not  be 
repeated  here  for  brevity. 

Correctness  of  the  Algorithms  with  Interval  Selection 

Below  we  show  that  the  minimum  and  maximum  algorithms  compute  the  minimum  and 
maximum  lengths  respectively  of  all  intervals  in  M  from  start  to  final  that  satisfy/ 

Lemma  21  An  interval  [jq,  ■s„]  in  the  model  M  satisfies /iff  there  is  a  corresponding 
interval  \pq,  ...,/?„]  in  the  product  P  that  starts  in  ({^qI  x  sat(j))  and  ends  in  ({5„}  xprop). 

Proof  For  the  first  direction,  note  that  the  existence  of  an  interval  corresponding  to  [59, ..., 
in  the  tableau  is  a  direct  consequence  of  theorem  16.  Lemma  8  guarantees  the  exist¬ 
ence  of  the  corresponding  interval  in  the  product  which  starts  in  ({  jq)  x  sat(f))  and  ends  in 
({Sn)  >^prop). 

For  the  second  direction,  lemma  8  demonstrates  the  existence  of  intervals  corresponding 
to  [pQ, ...,  Pn]  in  the  tableau  and  in  the  original  model  M.  Theorem  11  shows  that  since  the 
interval  in  the  tableau  starts  in  sat(f)  and  ends  in  prop,  then  it  satisfies  /.  Therefore, 
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because  their  labels  agree  on  the  propositional  variables  in/,  the  corresponding  interval  in 
the  original  model  also  satisfies/. 

Lemma  22  For  every  interval  [(to^'So)’  -» ^  with  /q  e  sat(f)  and  r„  ^prop,  the 
corresponding  interval  [jq,  5„]  in  Af  satisfies /. 

Proof  Given  an  interval  [(tQ,  5o)>  •••>  lemma  8  guarantees  the  existence  of  the 

corresponding  intervals  [^q,  in  M  and  [tQ, r„]  in  the  tableau.  Because  the  interval 

in  the  tableau  starts  in  sat(f)  and  ends  in  prop,  theorem  11  shows  that  it  satisfies  /.  But 
since  the  intervals  in  the  tableau  and  in  M  agree  on  the  propositional  variables  in  /,  if  [%, 

...,  satisfies/,  so  does  [jq,  — >  -Sn]- 

These  lemmas  imply  that  by  computing  the  minimum  and  maximum  lengths  of  intervals 
in  P  from  {start  x  satif))  to  (final  x  prop)  the  quantitative  algorithms  consider  all  the  inter¬ 
vals  in  M  from  start  to  final  that  satisfy  /,  and  only  those.  This  is  made  precise  by  the  fol¬ 
lowing  lemmas. 

Lemma  23  [Correctness  of  the  minimum  algorithm]  Let  st  =  (start  x  satif)),  fit  =  (final  x 
prop)  and  k  be  the  value  returned  by  minimum(st,fn)  applied  to  P. 

•  it  <  oo  is  the  size  of  a  shortest  interval  from  start  to  final  in  M,  that  satisfies/. 

•  If  ifc  =  oo  then  there  is  no  interval  from  start  to  final  in  M  that  satisfies  /. 

Proof  Assume  minimum(st,  fn)  is  applied  to  P.  By  the  correctness  proof  of  the  minimum 
algorithm  (see  section  5.2.1),  the  minimum  algorithm  returns  the  length  of  a  shortest  inter¬ 
val  from  (start  x  satif))  to  (final  x  prop)  in  P,  if  such  an  interval  exists  and  returns  infinity 
otherwise. 
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•  Assume  minimum{st,  fii)  returns  k.  By  Lemma  22,  there  is  an  interval  of  size  kixiM 
from  start  to  final  that  satisfies  /.  Suppose  there  is  a  shorter  such  interval  a.  By 
Lemma  21  there  is  a  corresponding  interval  in  P,  from  (start  x  sat(f))  to  {final  x  prop) 
of  the  same  size  as  a.  This  contradicts  the  correctness  of  the  minimum  algorithm. 
Hence,  k  is  the  size  of  a  required  interval  in  M. 

•  Assume  minimum(st,  fit)  returns  oo.  Further  assume  that  there  is  an  interval  of  size  k 
from  start  io  final  in  M,  that  satisfies/.  By  Lemma  21,  there  is  an  interval  of  the  same 
size  in  P  from  (start  x  satif))  to  (final  x  prop),  contradicting  the  correctness  of  the  min¬ 
imum  algorithm.  We  therefore  conclude  that  no  such  interval  exists  in  M. 

The  correctness  proof  of  the  selective  maximum  algorithm  is  based  on  the  properties  of 
the  maximum  algorithm  (see  section  5.2.2).  The  following  lemma  states  the  required 
property  for  the  non-selective  algorithm. 

Lemma  24  If  the  maximum(st,fii,  notjinal)  =  k  then  the  size  of  a  longest  interval  from  st, 
that  lies  entirely  within  notjinal  is  A:- 1.  If  it  returns then  there  is  no  bound  on  the  size  of 
such  intervals. 

Proof  The  proof  of  the  theorem  follows  very  closely  the  proof  of  the  maximum  algorithm 
in  section  5.2.2,  and  it  is  only  outlined  here.  The  following  two  definitions  are  used  in  the 
proof: 

•  Si  is  the  set  of  states  at  the  start  of  an  interval  with  i  states,  all  contained  in  notjnal. 

•  M  is  size  of  a  longest  interval  beginning  in  start  and  contained  within  notjinal. 

The  correctness  of  the  algorithm  follows  from  the  loop  invariants: 

•  i<M 

•  R  =  Si 

•  R'  =  Sm 
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Termination  is  guaranteed  because  there  can  be  no  infinite  sequence  of  distinct  5,  given 
that  the  state  space  is  finite  and  that  Si  3  5,+i. 

The  correctness  of  the  return  value  follows  from  the  last  conditional  in  the  algorithm.  If 
the  loop  is  exited  because  R  =  R',  then  Sj  =  Since  Sj+i  c  T  every  state  in  Sj+j 
has  an  edge  to  another  state  in  So  every  state  in  Si+i  is  the  beginning  of  an  infinite 
path  of  states  remaining  in  Sj+i  c  notjinal  Moreover,  R'  n  start  ^  0  (otherwise  the  algo¬ 
rithm  would  have  exited  inside  the  loop).  Therefore  some  state  s  e  Si+i  belongs  to  start. 
This  state  then  is  the  beginning  of  an  infinite  path  starting  at  a  state  in  start,  which  never 
reaches  a  state  in  final.  Infinity  is  then  correct  return  value. 

If n  start  =  0,  then  by  the  invariant  R'  =  Sj+i,  we  know  that  there  is  no  interval  of  i+1 
states  contained  in  notjinal  beginning  in  a  state  in  start.  No  longer  interval  can  exist  since 
this  would  contradict  the  absence  of  an  interval  of  i  +  1  states,  so  we  have  M  ^  i.  But  we 
also  have  the  invariant  i  <  M,  so  it  must  be  the  case  that  M  =  i,  which  is  the  correct  return 
value. 

Lemma  25  [Correctness  of  the  maximum  algorithm]  Let  st  =  (start  x  sat(f)),fii  =  (final  x 
prop), 

notjinal  =  -ifinalp  a  E[  -ifinalp  U  (propp  Afinal^] 
and  k  be  the  value  returned  by  maximum(st,fn,  notjnat)  when  applied  to  P. 

•  ik  <  oo  is  the  size  of  a  longest  interval  from  start  to  final  in  M,  that  satisfies/. 

•  If  jfc  =  CO  then  there  is  no  bound  on  the  sizes  of  the  intervals  from  start  to  final  in  M,  that 
satisfy/. 

Proof  If  maximum(st,  fit,  not  Jnal)  returns  k,  then  by  Lemma  24  the  size  of  a  longest 
interval  from  st  that  lies  entirely  within  not  Jnal  is  k-1.  Let  \pq,  ...,  Pk-\\  be  such  an  inter¬ 
val.  We  first  show  that  pjt-i  has  a  successor  pj^,  and  that  p^  t=  propp  Afinalp  In  other  words, 
Ph^  E  (final  X  prop). 
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The  state  p^.i  is  in  notjinal,  thus  1=  -nfinalp  a  E[  ->finalp  U  (propp  Afinalp)].  Since 
Pk-i  1=  -^finalp,  the  only  way  for  it  to  satisfy  also  E[  -ifinalp  U  (propp  Afinalp)]  is  by  hav¬ 
ing  a  successor pj^  such  that  p]^  ^  E[  —tfinalp  U  (propp  Afinalp]. 

Assume  that  pj,^finalp.  Then,  pj^  |=  ->fim^p  a  E[  afinalp  U  (propp  Afinalp)],  i.e.  pj,  e 
notjinal.  But  this  contradicts  the  fact  that  is  the  last  state  of  a  longest  interval.  Thus, 
p^  \=  final  and  since  it  satisfies  E[  -afinalp  U  (propp  Afinalp)],  it  must  also  satisfy  propp. 

Thus,  if  maximum(st,  fin,  notjnat)  returns  k,  k  is  the  size  of  a  longest  interval  from  st  = 
(start  X  sat(f))  to  fn  =  (final  x  prop)  in  P.  Using  arguments  similar  to  those  for  the  mini¬ 
mum  algorithm  we  conclude  that  the  size  of  the  longest  interval  from  start  to  final  in  M 
that  satisfies /is  k. 

The  proof  in  case  maximum(st,Jh,  notJnaJ)  returns  «>  also  follows  the  same  reasoning  as 
in  the  minimum  case. 


Correctness  of  the  Interval  Model  Checking  Algorithm 

Lemma  26  If  minimum(st,  fit)  applied  to  P  as  described  in  the  interval  model  checking 
algorithm  returns  infinity,  then  all  pure  intervals  in  M  satisfy  formula/. 

Proof  Lenuna  23  guarantees  that  if  minimum((start  x  sat(g)),  (final  x  prop))  returns  <», 
then  there  is  no  interval  from  start  to  final  in  M  that  satisfies  g.lf  g  =  — if,  this  means  that 
all  intervals  from  start  to  final  in  M  satisfy/.  We  conclude  that  all  pure  intervals  from  start 
to  final  in  M  satisfy/. 
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5.6  Lazy  Composition 

The  high  complexity  of  verifying  real-time  and  other  concurrent  systems  arises  mostly 
from  the  number  of  parallel  components  in  the  system.  The  number  of  states  of  the  state- 
transition  graph  representing  the  model  can  grow  exponentially  with  the  number  of  con¬ 
current  components  in  the  system.  Even  symbolic  algorithms  that  do  not  explicitly  repre¬ 
sent  individual  states  suffer  from  this  exponential  blowup.  However,  even  though 
extremely  expensive,  the  parallel  composition  algorithm  is  vital  to  verification  tools, 
because  the  large  majority  of  real  systems  is  described  by  a  set  of  concurrent  processes. 

Given  a  set  of  processes,  each  modeled  by  a  state-transition  graph,  a  parallel  composition 
algorithm  is  used  to  create  a  global  state-transition  graph  which  models  all  processes  and 
their  interaction.  There  are  different  ways  to  model  the  interaction  between  processes.  One 
common  way  is  the  synchronized  composition  model.  Under  this  model  one  step  in  the 
global  model  corresponds  to  exactly  one  step  in  each  process.  In  other  words,  all  processes 
execute  synchronously. 

Besides  synchronous  composition,  another  conunon  composition  model  is  interleaving 
composition.  In  this  model  only  one  process  executes  at  each  step  of  the  global  model. 
The  choice  of  which  process  executes  is  nondeterministic  and  fairness  assumptions  are 
used  to  avoid  starvation.  Interleaving  composition  is  not  well  suited  for  modeling  real¬ 
time  systems.  The  reason  is  that  since  the  choice  of  which  process  executes  next  is  nonde¬ 
terministic,  there  is  no  way  to  bound  the  execution  time  of  a  process.  While  fairness  can 
be  used  to  avoid  starvation,  it  cannot  be  used  to  bound  response  time.  Fairness  assump¬ 
tions  state  that  some  property  of  the  model  will  eventually  be  satisfied,  but  there  are  no 
restrictions  on  when  this  must  happen.  As  a  consequence,  any  process  can  always  be 
delayed  for  one  extra  step,  effectively  making  all  response  times  potentially  unbounded. 

In  Verus  the  synchronous  composition  model  is  used.  The  symbolic  parallel  composition 
algorithm  used  is  extremely  simple:  Given  a  set  of  boolean  formulas  Rq,  R^,  ..., 
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describing  the  transition  relation  of  each  process,  the  global  transition  relation  R  is  con¬ 
structed  by  conjuncting  all  RjS: 

^  ~  =  0..n  ^i- 

Each  Ri  is  a  formula  such  that  2?j(v,  v')  is  true  for  states  v  and  v'  iff  when  process  P,-  is  in 
state  V  it  can  transition  to  state  v'.  Consequently,  the  global  transition  relation  i?  is  a  for¬ 
mula  such  that  R(v,  v')  is  true  for  states  v  and  v'  iff  all  processes  can  transition  from  state  v 
to  state  v',  that  is,  all  processes  transition  at  the  same  time. 

Unfortunately,  the  size  of  i?  can  be  several  orders  of  magnitude  larger  than  the  sum  of  the 
sizes  of  all  R^  Some  techniques  exist  to  handle  this  blowup,  such  as  partitioned  transition 
relations  [8].  The  partitioned  transition  relation  algorithm  modifies  the  algorithm  to  com¬ 
pute  the  set  of  successors  of  a  state  set  S.  In  the  original  algorithm  S  is  conjuncted  with  the 
transition  relation  R  and  then  the  current  state  variables  are  quantified  out  of  the  result 
(See  “The  Model  Checking  Algorithm”  on  page  40.).  The  partitioned  transition  relation 
algorithm  changes  the  order  in  which  the  conjunction  and  quantification  are  performed. 

Partitioning  the  transition  relation  consists  of  dividing  it  into  separate  partitions,  in  much 
the  same  way  as  the  transition  relation  of  each  process  of  the  global  system  can  be  sepa¬ 
rated  from  the  others.  It  is  then  possible  to  quantify  out  variables  before  conjuncting  all 
components  when  computing  the  set  of  successors  of  a  state  set,  provided  that  those  vari¬ 
ables  are  not  used  by  the  unprocessed  partitions.  In  some  cases  significant  gains  can  be 
obtained  by  this  method,  since  the  global  transition  relation  is  never  constructed. 

The  problem  with  partitioned  transition  relations  is  that  they  are  very  sensitive  to  the  order 
in  which  processes  are  considered  for  early  quantification.  As  a  consequence,  in  order  to 
use  the  method  efficiently  the  user  must  understand  how  variables  interact  in  the  model, 
and  must  choose  the  right  order  to  apply  early  quantification. 

An  alternative  approach  is  used  in  Vems,  lazy  composition.  In  the  same  way  as  partitioned 
transition  relations  the  global  transition  relation  is  never  constructed.  However,  different 
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than  the  previous  method  a  restricted  transition  relation  of  all  processes  is  created  at  each 
step.  The  restricted  transition  relation  agrees  with  the  global  transition  relation  for  states  in 
the  state  set  of  interest,  but  it  may  behave  in  a  different  way  for  other  states.  The  advan¬ 
tage  comes  from  the  fact  that  in  many  cases  it  is  possible  to  construct  a  restricted  transition 
relation  that  is  significantly  smaller  than  the  global  transition  relation. 

There  are  many  possible  ways  of  constructing  a  restricted  transition  relation  that  would 
produce  correct  results.  Given  an  original  global  transition  relation  R  and  a  state  set/,  the 
computation  of  the  set  of  successors  of/ can  use  any  restricted  transition  relation  R'  that 
satisfies  the  following  condition: 

The  formula  above  means  that  R  and  R'  agree  on  transitions  that  start  in  states  in/.  It  is 
possible  to  represent  R'  with  significantly  fewer  nodes  that  R  in  some  cases  by  using  the 
constrain  operator  from  [26].  For  two  boolean  formulas /and  g,f  =  constrain(f,  g)  is  a 
formula  that  has  the  same  truth  value  as /for  variable  assignments  that  satisfy  g.  If  the 
variable  assignment  does  not  satisfy  g,  the  value  off  is  not  determined.  In  many  cases  the 
size  off  is  significantly  smaller  than  the  size  off. 

The  lazy  composition  algorithm  uses  the  constrain  operator  to  simplify  the  transition  rela¬ 
tion  of  each  process  before  generating  the  global  restricted  transition  relation.  When  com¬ 
puting  the  set  of  successors  of  a  state  set  5  (represented  by  a  boolean  formula)  the 
algorithm  computes: 


/?'  =  Aj-  _  o..n  constrainiRp  5) 

Each  transition  R'l  =  constrainfRi,  S)  agrees  with  /?,•  on  transitions  that  start  in  S  by  the 
definition  of  the  constrain  operator.  As  a  consequence,  the  transition  relation  R'  agrees 
with  the  global  transition  relation  R  on  transitions  that  start  S  as  well.  Therefore,  comput¬ 
ing  the  set  of  successors  of  S  using  R!  produces  the  same  result  as  using  R.  The  same 
method  can  be  applied  when  computing  the  set  of  predecessors  of  a  state  set. 
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The  constrain  operator  has  been  initially  used  to  simplify  the  set  of  states  visited  during 
verification  in  a  technique  called  frontier  set  simplification.  This  work  is  described 
in  [9,26].  The  same  operator  has  also  been  applied  to  simplify  the  transition  relation  in  a 
more  restricted  way  as  described  in  [62,73].  An  important  difference  between  these  meth¬ 
ods  and  ours  is  that  the  structure  of  the  Verus  language  makes  it  natural  to  partition  the 
transition  relation  into  processes.  In  a  well  designed  program  the  variables  that  interact 
more  closely  are  usually  in  the  same  process,  consequently  sharing  the  same  partition. 
This  makes  the  method  very  effective. 

We  have  implemented  the  lazy  composition  algorithm  and  obtained  significant  gains  in 
space  and  time  during  verification.  In  one  example  the  verification  was  previously  per¬ 
formed  in  40  seconds  using  12  megs  of  memory,  which  dropped  to  18  seconds  and  1  meg 
of  memory  using  the  proposed  method.  The  same  example  verified  with  partitioned  transi¬ 
tion  relations  used  about  the  same  time,  but  twice  the  memory  used  by  the  lazy  composi¬ 
tion  algorithm. 

A  significant  part  of  the  savings  come  from  not  constructing  the  global  transition  relation. 
These  savings  were  also  present  in  the  partitioned  transition  relation  case.  However  the 
new  method  used  much  less  memory.  The  reason  seems  to  be  that  partitioned  transition 
relations  are  heavily  influenced  by  the  order  in  which  partitions  are  processed,  because 
this  order  determines  which  variables  can  or  cannot  be  quantified  out  early.  In  the  pro¬ 
posed  method  this  does  not  happen,  all  variables  are  quantified  out  at  the  same  time.  This 
makes  it  less  susceptible  to  the  order  in  which  partitions  are  processed,  and  more  suitable 
to  be  used  in  the  cases  in  which  determining  the  processing  order  can  be  difficult.  It  also 
makes  the  new  technique  easier  to  automate. 
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Systems 


The  Verus  approach  is  a  practical  one.  It  can  be  (and  has  been)  applied  to  real  problems. 
This  chapter  describes  several  examples  that  have  been  verified  and  the  results  produced 
by  the  technique.  The  presentation  not  only  demonstrates  the  usefulness  of  the  method 
proposed,  but  also  explains  how  the  tool  can  be  used  and  how  results  can  be  interpreted.  In 
many  cases  our  analysis  has  been  able  not  only  to  determine  correctness,  but  also  to 
uncover  subtleties  in  the  behavior  of  the  system  being  verified  and  to  suggest  optimiza¬ 
tions.  These  examples  can  be  used  as  a  guide  to  verifying  other  systems.  The  method  is  by 
no  means  restricted  to  produce  the  types  of  information  described,  but  hopefully  the 
examples  presented  in  this  chapter  can  serve  as  a  starting  point  to  perform  similar  and 
even  more  complete  analyses  in  the  future. 


6.1  A  Priority  Inversion  Example 

Priorities  are  essential  in  real-time  systems.  The  correct  ordering  of  task  execution  is  a 
fundamental  problem  that  must  be  solved  if  the  system  is  to  be  predictable.  Many  schedul¬ 
ing  policies  have  been  developed  to  define  what  constitutes  a  correct  ordering  and  to 
enforce  this  ordering  during  the  execution  of  the  system.  Most  scheduling  policies  require 
that  higher  priority  tasks  execute  before  lower  priority  tasks.  However,  even  in  this  case,  it 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


141 


Analyzing  Real  Systems 

is  sometimes  possible  for  a  low  priority  process  to  be  executing  while  a  higher  priority  one 
is  blocked.  This  situation  is  called  priority  inversion  [66].  Unbounded  priority  inversions 
occur  when  high  priority  processes  are  blocked  indefinitely  by  low  priority  processes. 
When  this  happens,  the  system  becomes  unpredictable.  The  correct  ordering  of  task  exe¬ 
cution  will  be  compromised,  and  the  system  may  fail  to  satisfy  its  specification. 

In  order  to  present  the  problem  in  a  more  concrete  framework,  we  will  introduce  a  hypo¬ 
thetical  air-traffic  control  system.  This  example  is  not  associated  with  a  real  system,  but 
illustrates  a  problem  that  can  affect  virtually  any  real-time  system  and  cause  it  to  become 
unschedulable.  We  will  concentrate  our  analysis  in  two  of  the  processes  in  the  system.  The 
first,  called  sensor,  reads  airplane  position  data  from  radars,  sets  alarms  on  catastrophic 
conditions  (conditions  that  cannot  wait  for  a  detailed  analysis),  and  puts  the  data  into 
shared  memory.  The  other  process  is  the  reporter.  It  reads  the  data  collected  by  the  sensor, 
and  updates  the  traffic  controller  screens.  The  sensor  is  a  high  priority  process  since  it  pro¬ 
cesses  urgent  events,  and  must  not  be  blocked  by  other  processes.  The  reporter  on  the 
other  hand,  is  a  low  priority  process.  Since  it  doesn’t  process  urgent  events,  it  may  be 
delayed  by  other  more  important  tasks. 

The  sensor  and  the  reporter  processes  share  data.  To  access  shared  data  appropriately, 
synchronization  is  necessary.  In  our  system,  synchronization  is  implemented  by  a  mutex 
variable  which  guarantees  mutual  exclusion  among  the  processes  accessing  the  data.  The 
mutex  variable  is  locked  every  time  shared  data  is  accessed.  However,  this  may  result  in 
priority  inversion,  as  shown  in  the  following  scenario.  Suppose  the  reporter  is  inside  the 
critical  section,  and  the  sensor  tries  to  insert  new  data  into  the  buffer  area.  The  sensor 
can’t  access  the  data  and  blocks,  since  it  is  waiting  until  the  reporter  unlocks  the  mutex. 
At  this  point  a  high  priority  process  is  waiting  for  a  low  priority  one,  and  priority  inversion 
occurs.  This  situation  is  shown  in  figure  27.  This  figure  shows  which  process  is  executing 
at  any  time.  The  shaded  areas  indicate  that  the  process  is  accessing  the  mutual  exclusion 
area,  and  the  arrows  indicate  requests  for  and  releases  of  mutexes. 
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This  priority  inversion  scenario  is  bounded,  the  sensor  cannot  be  blocked  indefinitely.  The 
reporter  will  delay  the  sensor  only  while  it  is  inside  the  critical  section.  After  the  reporter 
releases  the  lock,  the  sensor  will  start  executing,  and  the  priority  inversion  will  disappear. 
We  can  calculate  the  maximum  duration  of  the  priority  inversion  as  the  time  to  execute  the 
largest  critical  section,  and  incorporate  it  in  our  calculations  for  the  execution  times.  The 
system  will  still  be  predictable,  although  there  may  be  a  little  loss  in  accuracy  in  execution 
time  predictions.  Consequently,  if  the  system  is  well  designed,  and  the  critical  sections  are 
small,  bounded  priority  inversions  can  be  tolerated  without  sacrificing  predictability. 


Screens  Radars 


Figure  27.  Bounded  priority  inversion 

In  certain  cases  it  is  possible  to  have  unbounded  priority  inversions  that  cannot  be  solved 
by  this  simple  method.  Suppose  a  third  process,  called  the  analyzer  is  added  to  the  system. 
This  process  reads  data  generated  by  other  components  of  the  air-traffic  controller  and 
processes  it.  The  analyzer  is  less  important  than  the  sensor  and  has  a  lower  priority.  But  it 
is  more  important  than  the  reporter,  since  urgent  conditions  may  arise  as  the  result  of  the 
analysis  and  handling  them  is  more  important  than  updating  the  screens.  Consider  now  the 
same  scenario  as  above,  with  the  reporter  inside  the  critical  section,  and  the  sensor  wait¬ 
ing  on  the  mutex.  At  this  point,  the  analyzer  starts  executing.  It  will  block  the  reporter, 
since  it  has  higher  priority.  However,  the  sensor  is  waiting  for  the  reporter  (and  therefore 
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also  for  the  analyzer).  Since  the  analyzer  doesn’t  know  the  relation  between  the  reporter 
and  the  sensor,  it  may  execute  for  an  unbounded  amount  of  time  and  delay  the  sensor 
indefinitely.  If  a  catastrophic  event  occurs,  it  will  go  unnoticed,  because  the  sensor  is 
blocked.  The  behavior  of  the  system  becomes  unpredictable.  This  unbounded  priority 
inversion  can  be  seen  in  figure  28. 


Priority  inheritance  protocols  are  one  way  of  preventing  unbounded  priority  inversions 
[66].  A  typical  protocol  might  work  in  the  following  manner.  As  soon  as  a  high  priority 
process  is  blocked  by  a  low  priority  one,  the  low  priority  process  is  temporarily  given  the 
priority  of  the  blocked  process.  In  our  example,  while  inside  the  critical  section  the  sensor 
is  trying  to  access,  the  reporter  will  execute  at  high  priority.  When  the  reporter  exits  the 
critical  section,  it  will  be  restored  to  its  original  priority.  In  this  way,  the  analyzer  will  not 
be  able  to  interrupt  the  reporter  when  the  sensor  is  waiting.  We  will  show  that  this  proto¬ 
col  avoids  the  unbounded  priority  inversion  problem  (except  possibly  for  deadlocks  in 
accessing  synchronization  variables).  This  allows  the  designer  of  the  system  to  predict  the 
maximum  priority  inversion  time,  as  in  the  bounded  case. 
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Figure  28.  Unbounded  priority  inversion 
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Priority  inversion  occurred  in  this  example  because  the  analyzer  preempted  the  reporter. 
Another  cause  of  priority  inversion  is  queueing.  Communication  protocols  may  experi¬ 
ence  priority  inversion  for  this  reason.  For  example,  packets  to  be  sent  to  the  network  may 
have  priorities.  Low  priority  packets  may  be  enqueued  ahead  of  high  priority  ones  in  some 
protocol  queue.  In  a  prioritized  network  a  high  priority  packet  may  have  to  wait  for  a  low 
priority  one  to  be  sent.  If  medium  priority  packets  start  arriving  in  another  processor’s 
queue,  they  may  monopolize  the  network,  preventing  high  priority  packets  from  being 
sent.  Again,  we  have  unbounded  priority  inversion.  This  type  of  priority  inversion  could 
also  happen  in  our  system,  if  the  different  components  were  distributed  over  a  network. 
For  example,  sensor  packets  could  be  queued  after  some  low  priority  packets  in  a  queue, 
while  analyzer  packets  were  being  transmitted. 

The  inheritance  mechanism  that  we  have  described  to  avoid  unbounded  inversions  is 
called  basic  priority  inheritance  protocol.  There  are  other  priority  inheritance  protocols. 
Some  protocols  are  designed  to  avoid  deadlocks  caused  when  critical  sections  are 
accessed  in  the  wrong  order.  Other  protocols  are  designed  to  handle  chained  bounded  pri¬ 
ority  inversions.  A  chained  inversion  occurs  when  a  high  priority  process  wants  to  lock 
n  mutexes  that  are  already  locked  by  low  priority  processes.  In  this  case,  the  high  priority 
process  has  to  wait  for  all  low  priority  processes  to  finish  their  critical  sections.  While  this 
wait  is  bounded,  it  may  be  too  expensive  to  wait  for  the  duration  of  all  critical  sections. 
One  possible  solution  to  this  problem  is  to  assign  priorities  to  critical  sections,  based  on 
the  priorities  of  the  processes  that  may  access  it.  A  process  is  allowed  to  access  a  critical 
section  only  if  its  priority  is  higher  than  the  priority  of  all  critical  sections  currently  being 
accessed.  A  more  complete  study  of  these  various  algorithms  and  their  characteristics  can 
be  found  in  [66]. 

We  have  used  Verus  to  implement  and  analyze  a  real-time  system  that  is  susceptible  to  pri¬ 
ority  inversion.  The  example  follows  the  sensor— analyzer — reporter  paradigm  presented 
above,  but  with  some  important  differences.  There  is  no  scheduler  choosing  which  process 
runs  next,  all  processes  run  concurrently.  However,  a  mutex  control  module  chooses 
which  process  will  lock  the  variable  next,  and  when  there  is  contention,  high  priority  pro- 
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cesses  are  chosen  first.  In  this  case  the  queueing  of  processes  in  the  mutex  control  module 
may  cause  priority  inversion.  In  the  example  we  have  the  same  three  processes  as  above, 
the  sensor,  the  analyzer  and  the  reporter,  with  high,  medium  and  low  priorities,  respec¬ 
tively.  There  are  also  two  mutex  variables.  Ml  and  M2,  controlling  two  critical  sections. 
The  sensor  uses  the  critical  section  controlled  by  Ml,  the  analyzer  uses  the  one  controlled 
by  M2,  and  the  reporter  locks  both  variables,  first  Ml  and  then  M2.  The  mutex  Ml  controls 
access  to  the  area  shared  by  the  sensor  and  the  reporter  as  explained  above.  The  mutex  M2 
controls  a  shared  area  where  the  analyzer  puts  its  results.  These  results  will  in  turn  be  read 
by  the  reporter  to  be  printed  on  the  screen.  The  Verus  code  that  implements  the  system  is 
given  below.  We  start  by  presenting  the  simplest  version  that  suffers  from  priority  inver¬ 
sion,  and  then  proceed  to  change  the  design  to  correct  the  problem. 

1  sensor (Ml,  req) 

2  int  Ml ; 

3  boolean  req; 

3  { 

4  extern  boolean  proceed; 

5  boolean  start,  finish; 

6 

7  req  =  false; 

8  start  =  false;  finish  =  false; 


The  parameters  and  local  variables  of  the  sensor  are  declared  above.  The  parameter  Ml  is 
the  first  mutex  variable,  and  req  is  used  by  sensor  to  request  access  to  Ml.  The  variable 
proceed  is  used  to  decide  when  the  process  will  try  to  lock  Ml.  It  can  wait  indefinitely 
outside  the  critical  region,  but  it  can  also  decide  at  any  time  to  proceed.  By  declaring 
proceed  as  an  external  variable,  we  allow  it  to  change  non-deterministically,  effectively 
modeling  the  desired  behavior,  as  will  be  seen  shortly.  The  variables  start  and  finish 
are  used  to  flag  the  beginning  and  end  of  execution  of  sensor. 
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The  sensor  executes  continuously.  Line  9  starts  an  infinite  loop  inside  which  sensor  exe¬ 
cutes.  Line  10  stops  the  process  until  the  variable  proceed  is  true.  Since  proceed  is  an 
external  variable,  it  can  become  true  at  any  time.  The  process  will  then  wait  for  a  non- 
deterministic  amount  of  time  before  proceeding.  This  models  the  behavior  that  sensor  may 
decide  to  access  the  critical  region  at  any  time,  or  never  at  all. 

9  while  (true)  { 

10  while  (Iproceed)  wait(l); 

Once  it  decides  to  proceed,  sensor  flags  that  it  wants  to  access  the  mutual  exclusion  region 
in  line  1 1  by  asserting  the  variable  r  eq.  This  variable  is  used  by  the  mutex  control  module 
to  decide  which  process  accesses  the  mutual  exclusion  region  first.  In  line  12  the  process 
flags  that  it  has  started  executing  and  waits  until  the  mutex  variable  Ml  indicates  that  it  has 
been  granted  the  mutual  exclusion  region  (line  13).  The  process  rt_mutex  (described 
below)  guarantees  that  only  one  process  at  any  point  will  be  granted  mutual  exclusion. 


11 

req  = 

true  ; 

12 

start 

=  true; 

13 

while 

(Ml  !=  1)  {wait(l);  start  =  false;  }; 

Lines  14  to  16  correspond  to  the  sensor  accessing  the  critical  region  for  three  time  units. 
Notice  that  the  variable  start  is  asserted  in  line  12  and  deasserted  either  in  line  13  or  15. 
This  pattern  guarantees  that  start  will  be  true  for  only  one  time  unit,  when  sensor 
decides  to  execute.  It  is  important  for  the  computation  of  accurate  response  times  that  it  is 
asserted  for  only  one  time  unit.  For  example,  if  start  is  not  deasserted  in  line  13  after 
the  wait,  start  would  correspond  to  the  time  interval  between  requesting  the  mutual 
exclusion  until  it  is  granted,  and  not  the  time  instant  that  the  process  starts  executing. 


14 

wait (1)  ; 

/*  Ml  is  locked  */ 

15 

start  =  false; 

16 

wait (2 ) ; 
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Line  17  signals  the  mutex  control  module  that  sensor  does  not  require  mutual  exclusion 
anymore.  Line  18  flags  that  it  has  ended  its  execution.  Line  20  is  used  to  guarantee  that 
finish  is  also  asserted  for  only  one  time  unit.  Line  19  is  important  to  make  the  effect  of 
line  18  observable  to  other  processes.  If  there  was  no  wait  statement  in  line  19,  the  vari¬ 
able  finish  would  be  asserted  and  deasserted  in  the  same  cycle,  nullifying  the  assertion. 

17  req  =  false; 

18  finish  =  true; 

19  wait(l);  /*  Ml  is  unlocked  */ 

20  finish  =  false; 

21  }; 

22  } 


The  analyzer  process  is  shown  above.  It  is  very  similar  to  the  sensor  process,  except  that  it 
requests  the  mutex  M2  instead  of  Ml. 


23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 


analyzer (M2 ,  req) 
int  M2 ; 
boolean  req; 

{ 

extern  boolean  proceed; 
boolean  start,  finish; 

req  =  false; 

start  =  false;  finish  =  false; 
while  (true)  { 

while  (Iproceed)  wait(l); 
req  =  true; 
start  =  true; 

while  (M2  !=  2)  {wait(l);  start  =  false,-}; 
wait(l) ;  /*  M2  is  locked  */ 

start  =  false; 
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39  wait (2); 

40  req  =  false; 

41  finish  =  true; 

42  wait(l);  /*  M2  is  unlocked  */ 

43  finish  =  false; 

44  }; 

45  } 

The  reporter  has  a  similar  structure  to  both  the  sensor  and  the  analyzer .  The  main  differ¬ 
ence  is  that  it  accesses  both  Ml  and  M2. 


46 

reporter (Ml ,  M2 , 

reqMl ,  reqM2 ) 

47 

int  Ml,  M2; 

48 

boolean  reqMl ,  reqM2 ; 

49 

{ 

50 

extern  boolean  proceed; 

51 

boolean  start. 

finish; 

52 

53 

reqMl  =  false; 

reqM2  =  false; 

54 

start  =  false; 

finish  =  false 

55 

while  (true)  { 

56 

while  (Iproceed)  wait(l); 

Initially,  the  reporter  requests  Ml. 


57 

reqMl  =  true; 

58 

start  =  true; 

59 

while  (Ml  !=  3) 

{wait (1) ; 

start  =  false;}; 

60 

wait (1)  ; 

/*  Ml 

is  locked  */ 

61 

start  =  false; 

Once  Ml  is  locked,  the  reporter  locks  M2. 
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62 

reqM2  =  true ; 

63 

while  (M2  ! =  3 ) 

wait (1) ; 

64 

wait (3 ) ; 

/*  M2  is  locked  */ 

Finally,  it  unlocks  both  mutexes. 

65  reqM2  =  false; 

66  regMl  =  false; 

67  finish  =  true; 

68  wait(l);  /*  both  are  unlocked  */ 

69  finish  =  false; 

70  }; 

71  } 

The  process  that  controls  access  to  the  mutual  exclusion  regions  is  shown  next.  It  has  as 
outputs  the  mutex  variables  Ml  and  M2.  The  inputs  are  the  requests  from  all  processes, 
s_reqMl  comes  from  the  sensor,  a_reqM2  comes  from  the  analyzer,  and  r_reqMl 
and  r_reqM2  come  from  the  reporter. 

72  rt_mutex (Ml ,  M2 , 

73  s_reqMl ,  a_reqM2 ,  r_reqMl ,  r_reqM2 ) 

74  int  Ml,  M2; 

75  boolean  s_reqMl,  a_reqM2,  r_reqMl,  r_reqM2; 

76  { 

Initially  both  mutexes  are  unlocked.  The  process  then  enters  an  infinite  loop  in  which  it 
receives  requests  and  grants  mutexes.  The  decision  is  based  on  a  straightforward  policy,  if 
no  one  is  requesting,  the  mutex  stays  unlocked  (line  80).  If  only  one  process  is  requesting, 
the  mutex  is  granted  to  it  (lines  81  and  82).  If  both  are  requesting  (line  83)  the  mutex  is 
granted  to  process  1  (the  sensor),  since  it  has  higher  priority.  The  lower  priority  process 
may  starve  according  to  this  policy,  but  this  is  allowed  in  real-time  resource  management. 
Notice  that  if  there  is  contention  we  must  wait  until  the  current  owner  of  the  mutex 
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releases  it  before  changing  its  value.  This  is  needed  because  mutual  exclusion  regions  can¬ 
not  be  preempted. 


77 

Ml  = 

0; 

78 

M2  = 

0; 

79 

while 

( true )  { 

80 

if 

( ! s_reqMl 

ScSc 

1  r_reqMl ) 

Ml  =  0; 

else 

81 

if 

(  s_reqMl 

ScSc 

!  r_reqMl ) 

Ml  =  1; 

else 

82 

if 

( ! s_reqMl 

ScSc 

r_reqMl ) 

Ml  =  3; 

else 

83 

if 

(Ml  ==  0) 

Ml  =  1; 

The  rt_mutex  process  is  completed  by  handling  M2  in  the  same  way  as  Ml. 


84 

if  (!a_reqM2 

ScSc 

!  r_reqM2 ) 

M2  =  0; 

else 

85 

if  (  a_reqM2 

ScSc 

! r_reqM2 ) 

M2  =  2; 

else 

86 

if  ( ! a_reqM2 

ScSc 

r_reqM2 ) 

M2  =  3; 

else 

87 

if  (M2  ==  0) 

M2  =2; 

88 

wait (1) ; 

89 

}; 

90 

} 

Finally,  main  declares  the  mutex  variables  and  instantiates  all  processes. 

91  main ( ) 

92  { 

93  int  Ml,  M2; 

94  boolean  s_reqMl,  a_reqM2,  r_reqMl,  r_reqM2 ; 

95 

96  process 

97  pi  sensor (Ml,  s_reqMl) , 

98  p2  analyzer (M2 ,  a_reqM2 ) , 

99  p3  reporter (Ml ,  M2 ,  r_reqMl ,  r_reqM2 ) , 
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100  pO  rt_mutex(Ml,  M2,  s_reqMl,  a_regM2, 

101  r_reqMl ,  r_reqM2 ) ; 

102  } 

Stuttering 

The  program  presented  above  implements  the  system  described.  However,  one  of  the 
characteristics  of  the  model  generated  from  this  program  differs  from  the  actual  system.  In 
Verus  all  processes  are  synchronized,  that  is,  one  step  of  the  global  model  corresponds  to 
exactly  one  step  in  each  process.  In  the  actual  implementation  of  the  system  this  is  not  a 
correct  assumption,  processes  execute  asynchronously.  This  has  important  consequences 
in  the  behavior  of  the  model.  For  example,  in  the  model  above  unbounded  priority  inver¬ 
sion  does  not  occur,  it  is  avoided  by  the  implicit  dependencies  introduced  by  the  synchro¬ 
nization  of  the  modules.  However,  these  dependencies  do  not  exist  in  the  real  system,  and 
must  be  eliminated.  This  is  accomplished  by  a  technique  called  stuttering.  It  has  the  effect 
of  making  a  transition  in  the  model  take  a  nondeterministic  number  of  time  units  to  occur, 
eliminating  implicit  synchronization  dependencies.  An  improved  rt_mutex  process  is 
shown  below  that  models  the  correct  asynchronous  behavior.  The  integer  variable  s  tut  is 
used  to  determine  when  mutex  decisions  should  take  place.  A  decision  about  granting  the 
mutex  must  be  made  if  stut  is  zero,  but  it  may  or  may  not  be  made  otherwise.  Since 
stut  is  continuously  incremented  (modulo  10),  a  decision  can  be  delayed  up  to  10  time 
units,  but  no  longer. 

The  difference  between  the  original  rt_mutex  and  the  new  one  is  the  use  of  the  stut 
variable.  Lines  81  and  82  have  been  replaced,  now  the  decision  about  granting  the  mutex 
depends  on  the  value  of  stut. 

72  rt_mutex (Ml ,  M2 , 

73  s_reqMl ,  a_reqM2 ,  r_reqMl ,  r_reqM2 ) 

74  int  Ml ,  M2 ; 

75  boolean  s_reqMl,  a_reqM2,  r_reqMl,  r_reqM2 ; 

76  { 
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int  stut; 


Ml  =  0; 

M2  =  0; 

while  (true)  { 

if  ( ! s_reqMl  &&  !r_reqMl)  Ml  =  0;  else 
if  (  s_reqMl  &&  !r_reqMl  &&  Ml  !=  1)  { 
if  (stut  ==  0)  Ml  =  1;  else 

Ml  =  select {0,  1}; 

}  else 

if  ( ! s_reqMl  &&  r_reqMl  &&  Ml  !=  3)  { 
if  (stut  ==  0)  Ml  =  3;  else 


}  else 
if  (Ml  ==  0) 


Ml  =  select {0,  3); 


Ml  =  1; 


Mutex  M2  is  handled  in  the  same  way. 


if  (!a_reqM2  &&  !r_reqM2)  M2  =  0;  else 
if  (  a_reqM2  &&  !r_reqM2  &&  M2  !=  2)  { 
if  (stut  ==  0)  M2  =  2;  else 

M2  =  select {0,  2}; 

}  else 

if  (!a_reqM2  &.&  r_reqM2  &&  M2  !=  3)  { 
if  (stut  ==  0)  M2  =  3;  else 

M2  =  select {0,  3}; 


}  else 
if  (M2  ==  O: 


M2  =  2; 


Finally,  the  value  of  stut  is  incremented  at  each  step  as  seen  below.  The  value  is  contin¬ 
uously  incremented  modulo  10. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


153 


Analyzing  Rea!  Systems 


100  if  (stut  <  10)  stut  =  stut  +  1;  else 

101  stut  =  0; 

102  wait(l); 

103  }  ; 

104  } 

We  have  analyzed  the  model  above  using  RTCTL  model  checking  and  the  quantitative 
algorithms  described.  The  first  property  .verified  is  mutual  exclusion.  One  way  to  check  if 
the  access  to  the  critical  sessions  is  exclusive  is  to  create  variables  that  are  asserted  when 
the  process  enters  the  critical  region,  and  deasserted  when  it  leaves  the  region.  These  vari¬ 
ables  are  similar  to  the  start  and  finish  variables  presented  above.  We  can  then  write 
a  CTL  formula  that  states  that  no  two  of  these  variables  are  asserted  at  the  same  time. 

There  is  another  way  of  checking  the  same  property  without  adding  variables  to  the 
model.  Notice  that  each  process  is  inside  the  critical  region  when  it  goes  through  some 
specific  wait  statements  in  the  program.  The  sensor  processor  is  inside  the  critical  region 
controlled  by  Ml  when  it  executes  the  wait  statements  3, 4  and  5  in  the  source  code.  The 
analyzer  is  inside  M2  when  it  executes  waits  3, 4  and  5.  The  reporter  is  inside  Ml  when  it 
executes  the  waits  between  3  and  7,  and  inside  M2  when  it  executes  waits  5  to  7. 

Since  the  wait  counters  are  variables  in  the  model,  it  is  possible  to  write  CTL  formulas 
that  reference  them  and  check  to  see  if  any  critical  region  is  being  violated.  The  region 
controlled  by  Ml  can  be  checked  by  the  formula: 

AG  !  [sensor_in_Ml  &&  reporter _in_Ml) 
where  sensor_in_Ml  is 

( sensor. wc  ==  3  | |  sensor. wc  ==  4  | |  sensor. wc  ==  5) 

and  reporter_in_Ml  is 

(reporter. wc  ==  3  |  |  reporter. wc  ==  4  |  1  reporter. wc  ==  5  |  | 
reporter. wc  ==  6  | |  reporter. wc  ==  7)) 
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Finally,  the  region  controlled  by  M2  is  checked  by  the  formula: 

AG  !  {analyzerJn_M2  &&  reporterJn_M2) 

where  analyzer_in_M2  is 

( analyzer. wc  ==  3  | |  analyzer. wc  ==  4  | ]  analyzer. wc  ==  5) 
and  reporter _in_M2  is 

(reporter. wc  ==  5  | [  reporter. wc  ==  6  | |  reporter. wc  ==  7) 

Properties  about  the  response  time  of  the  processes  in  the  model  have  also  been  checked. 
We  have  found  that  the  analyzer  has  a  bounded  response  time,  the  following  property  is 
true  of  the  model: 

PiG(analyzer.start  AF<  15  analyzer.finish) 

However,  the  sensor  process  can  starve.  The  following  sequence  of  events  leads  to  an 
unbounded  priority  inversion: 

•  The  reporter  locks  Ml. 

•  The  anu/yzer  locks  M2. 

•  The  sensor  wants  to  lock  Ml,  but  it  is  already  locked,  so  it  waits. 

•  The  reporter  wants  to  lock  M2,  but  it  is  locked,  so  it  waits. 

•  The  analyzer  is  continuously  generating  data,  and  after  unlocking  M2,  it  locks  the 
mutex  again  to  insert  new  data  into  the  buffer.  The  reporter  never  locks  M2,  since  it  has 
lower  priority  than  the  analyzer. 

•  The  sensor  is  waiting  for  the  reporter,  and  the  reporter  is  waiting  indefinitely  for  the 
analyzer.  Therefore,  the  sensor  is  blocked  by  the  analyzer  indefinitely. 

We  have  implemented  the  basic  priority  inheritance  protocol  described  previously  to  solve 
this  problem.  The  solution  works  as  follows.  Whenever  the  sensor  is  waiting  for  the 
reporter,  the  task  being  executed  by  the  reporter  becomes  a  high  priority  task.  We  then 
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make  the  reporter  a  high  priority  process  temporarily,  so  it  will  release  the  lock  the  sensor 
wants  faster.  The  ana/yzcr  eventually  notices  that  the  reporter  has  become  a  high  priority 
process.  At  this  point  it  will  yield  M2  to  the  reporter.  After  unlocking  Ml,  the  reporter  will 
have  its  old  priority  restored. 

To  implement  priority  inheritance  we  can  easily  change  the  Verus  program  above.  A  bool¬ 
ean  variable  M2  inherit  is  declared.  It  will  signal  when  the  priority  inheritance  mecha¬ 
nism  must  be  activated.  The  initial  value  for  this  variable  is  false,  and  it  becomes  true 
whenever  the  sensor  tries  to  lock  Ml.  In  the  code  for  the  sensor  process,  lines  13  and  14 
are  replaced  by: 

13  while  (Ml  !=  1)  { 

14  M2 inherit  =  true; 

15  wait (1) ; 

16  start  =  false; 

17  }; 

18  wait(l);  /*  Ml  is  locked  */ 

19  M2 inherit  =  false; 

In  the  rt_mutex  process  we  must  make  sure  that  whenever  M2  inherit  is  true,  the 
reporter  is  given  priority  over  the  analyzer.  This  is  implemented  by  replacing  line  99  in  the 
rt_inutex  code  by: 

99  if  (M2  ==  0)  { 

100  if  (M2inherit)  M2  =  3;  else 

101  M2  =  2; 

102  }  ; 

The  modifications  proposed  guarantee  that  there  is  no  unbounded  priority  inversion  in  the 
system.  The  sensor  now  has  a  bounded  response  time,  as  attested  by  the  following  prop¬ 
erty  of  the  model: 

AG(sensor.start  AF<  30  sensor.finish) 
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In  fact,  by  using  quantitative  analysis  we  have  determined  the  exact  best  and  worst  case 
response  times  for  the  processes: 


Process 

Min.  time 

Max.  time 

sensor 

3 

26 

analyzer 

3 

oo 

reporter 

4 

oo 

Conclusions 

This  example  shows  that  priority  inversion  is  an  important  problem  that  can  affect  the 
behavior  of  real-time  systems  in  subtle  but  significant  ways.  It  can  make  even  simple  sys¬ 
tems  unpredictable.  In  the  example  we  also  discuss  a  solution,  priority  inheritance,  and 
show  how  it  can  make  the  system  predictable  by  bounding  the  maximum  priority  inver¬ 
sion  time. 

We  also  demonstrate  in  this  example  how  the  Verus  language  can  be  used  to  specify  and 
analyze  a  real-time  system.  The  Verus  code  for  the  system  is  fully  presented  as  well  as  its 
analysis.  It  shows  how  Verus  can  be  used  to  describe  and  analyze  complex  systems.  The 
description  is  detailed  enough  to  hopefully  serve  as  a  starting  point  for  writing  programs 
describing  similar  systems.  The  analysis  performed  is  very  straightforward,  but  this  is  by 
no  means  a  restriction  on  the  method.  The  following  sections  will  describe  more  sophisti¬ 
cated  examples  and  analyses. 


6.2  An  Aircraft  Controller 

One  of  the  most  critical  applications  of  real-time  systems  is  in  aircraft  control.  It  is 
extremely  important  that  time  bounds  are  not  violated  in  such  systems.  This  section  briefly 
describes  an  aircraft  control  system  used  in  military  airplanes.  We  have  attempted  to  make 
this  model  as  realistic  as  possible.  It  is  shown  how  some  of  its  timing  constraints  can  be 
checked  using  the  quantitative  algorithms  described. 
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System  Description 

The  control  system  for  an  airplane  can  be  characterized  by  a  set  of  sensors  and  actuators 
connected  to  a  central  processor.  This  processor  executes  the  software  to  analyze  sensor 
data  and  control  the  actuators.  Our  model  describes  this  control  program  and  defines  its 
requirements  so  that  the  specifications  for  the  airplane  are  met.  The  requirements  used  are 
similar  to  those  of  existing  military  aircraft,  and  are  derived  from  those  described  in  [60]. 

The  aircraft  controller  is  divided  into  systems  and  subsystems.  Each  system  performs  a 
specific  task  in  controlling  a  component  of  the  airplane.  The  most  important  systems  are 
implemented  in  our  model  to  provide  a  realistic  representation  of  the  controller.  The  sys¬ 
tems  being  controlled  are: 

•  Navigation:  Computes  aircraft  position.  Takes  into  account  data  such  as  speed,  altitude, 
and  positioning  data  received  from  satellites  or  ground  stations. 

•  Radar  Control:  Receives  and  processes  data  from  radars.  It  also  identifies  targets  and 
target  position. 

•  Radar  Warning  Receiver:  This  system  identifies  possible  threats  to  the  aircraft. 

•  Weapon  Control:  Aims  and  activates  aircraft  weapons. 

•  Display:  Updates  information  on  the  pilot’s  screen. 

•  Tracking;  Updates  target  position.  Data  from  this  system  are  used  to  aim  the  weapons. 

•  Data  Bus:  Provides  communication  between  processor  and  external  devices. 

Each  system  is  composed  of  one  or  more  subsystems.  Timing  constraints  for  each  sub¬ 
system  are  derived  from  factors  such  as  required  accuracy,  human  response  characteristics 
and  hardware  requirements.  For  example,  the  screen  must  be  updated  frequently  enough 
so  that  motion  appears  continuous.  To  accomplish  this,  the  update  must  occur  at  least  once 
every  50  ms.  The  following  table  presents  the  subsystems  being  modelled,  as  well  as  their 
major  timing  requirements.  The  priority  assignment  will  be  explained  subsequently. 
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System 

Subsystem 

Period 

Execution 

Time 

%  CPU 
Utilization 

Priority 

Display 

status  update 

200 

3 

1.50 

12 

keyset 

200 

1 

0.50 

16 

hook  update 

80 

2 

2.50 

36 

graphic  display 

80 

9 

11.25 

40 

store  update 

200 

1 

0.50 

20 

RWR 

contact  mgmt. 

25 

5 

20.00 

72 

Radar 

target  update 

50 

5 

10.00 

60 

tracking  filter 

25 

2 

8.00 

84 

NAV 

nav  update 

.  50 

8 

16.00 

56 

steering  cmds. 

200 

3 

1.50 

24 

Tracking 

target  update 

100 

5 

5.00 

32 

Weapon 

weapon  protocol 

O 

o 

1 

0.50 

28 

weapon  aim 

50 

3 

6.00 

64 

weapon  release 

200^ 

3 

1.50 

98 

Data  Bus 

poll  bus  devices 

40 

1 

2.50 

68 

^  Weapon  protocol  is  an  aperiodic  process  with  a  deadline  of  200  ms, 
^  Weapon  release  has  a  period  of  200  ms,  but  its  deadline  is  5  ms. 


Figure  29.  Timing  requirements  for  aircraft  controller 

Concurrent  processes  are  used  to  implement  each  subsystem.  Communication  among  the 
various  processes  is  done  indirectly.  No  data  are  shared  directly  by  two  subsystems.  Pro¬ 
cesses  communicate  only  through  data  servers  called  monitor  tasks.  Each  system  main¬ 
tains  a  server  process  tfiat  accepts  requests  for  data,  and  returns  the  desired  information. 
The  various  subsystems  in  each  system  update  the  data  in  the  servers.  Monitor  tasks  only 
accept  requests,  respond  to  them,  and  then  block.  They  are  assigned  low  priority,  and  pri¬ 
ority  inheritance  is  used  to  maintain  predictability  [1 1,66]. 
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With  the  exception  of  the  weapon  system,  all  other  systems  contain  only  periodic  pro¬ 
cesses,  which  are  scheduled  to  execute  at  the  beginning  of  their  period.  When  a  process  is 
granted  the  CPU  it  acquires  the  data  it  needs  through  the  monitor  tasks,  executes,  updates 
information  on  its  own  data  server,  and  blocks  waiting  for  its  next  execution  period. 

The  weapon  system  contains  a  mixture  of  periodic  and  aperiodic  processes.  It  is  activated 
when  the  display  keyset  subsystem  identifies  that  the  pilot  has  pressed  the  firing  button. 
This  event  causes  the  weapon  protocol  subsystem  to  be  activated.  It  then  signals  the 
weapon  aim  subsystem  that  had  been  blocked.  Weapon  aim  is  then  scheduled  to  be  exe¬ 
cuted  every  50  ms.  It  aims  the  aircraft  weapons  based  on  the  current  position  of  the  target. 
It  also  decides  when  to  fire  and  then  starts  the  weapon  release  subsystem.  The  firing 
sequence  can  be  aborted  until  weapon  release  is  scheduled,  but  not  after  this  point. 
Weapon  release  then  executes  periodically  and  fires  the  weapons  5  times,  once  per  second. 

In  order  to  enforce  the  different  timing  constraints  of  the  processes,  priority  scheduling  is 
used.  Predictability  is  guaranteed  by  scheduling  the  processes  using  Rate  Monotonic 
Scheduling  (RMS)  [50,59]. 

Model  of  the  Aircraft  Control  System 

We  have  modeled  this  control  system  in  the  Verus  system.  Model  checking  has  been  used 
to  verify  its  functional  correctness,  while  its  timing  correctness  has  been  checked  using 
the  quantitative  algorithms  described  previously.  Most  of  the  characteristics  described 
above  were  implemented,  although  some  abstractions  have  been  performed  for  simplicity. 
A  more  detailed  description  of  the  implementation  follows. 

A  time  quantum  of  1  ms  was  used,  in  other  words,  a  transition  corresponds  to  a  delay  of 
1  ms  in  our  model.  A  global  timer  is  implemented  that  starts  periodic  processes  when  their 
period  arrives.  Whenever  awakened,  a  process  requests  execution  and  waits  until  it  has 
been  granted  the  CPU.  The  process  then  mns  for  its  defined  execution  time.  An  internal 
counter  stores  the  time  since  execution  has  started.  After  executing,  the  process  releases 
the  CPU  and  blocks,  waiting  for  the  next  period. 
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The  time  to  request  data  from  a  monitor  task  and  wait  for  the  response  is  assumed  to  be 
small  compared  to  the  total  execution  time.  This  is  reasonable  if  we  assume  an  efficient 
implementation.  Sending  request  and  response  messages  takes  only  a  small  amount  of 
time.  Processing  in  the  monitor  tasks  is  also  fast,  considering  the  limited  range  of  func¬ 
tions  performed.  The  assumption  can  only  be  violated  if  blocking  due  to  synchronization 
is  long.  The  access  pattern  to  the  monitor  tasks,  however,  minimizes  this  possibility.  They 
simply  receive  requests,  retrieve  data  from  memory,  and  return  it.  There  are  no  nested  crit¬ 
ical  sections.  Moreover,  the  priority  inheritance  protocols  used  maintain  predictability  and 

eliminate  the  possibility  of  unbounded  blocking  due  to  synchronization  [11,66].  Since 
blocking  times  can  be  computed,  we  assume  they  are  included  in  the  execution  time 
defined.  A  more  detailed  model  can  be  constructed  to  remove  this  assumption,  but  because 
of  the  reasons  outlined  above,  we  believe  this  would  not  change  the  results  significantly. 
In  order  to  optimize  response  time,  we  have  implemented  a  preemptive  scheduler.lt 
accepts  requests  for  execution  and  chooses  the  highest  priority  process  requesting  the 
CPU.  If  a  request  arrives  from  a  higher  priority  process  after  execution  has  started,  the 
scheduler  preempts  the  executing  process  and  starts  the  higher  priority  one.  When 
a  process  finishes  executing  it  resets  its  request,  and  the  scheduler  chooses  another  pro¬ 
cess.  If  data  were  shared  directly,  synchronization  could  cause  deadlocks.  This  could  hap¬ 
pen,  for  example  because  of  cyclic  dependencies  among  locks.  Monitor  tasks  avoid  this 
problem  because  they  eliminate  the  possibility  of  complex  data  dependencies. 

We  have  also  implemented  a  non-preemptive  scheduler.  Preemptability  is  a  feature  that 
may  not  always  be  available,  and  we  wanted  to  observe  the  effects  of  removing  this  fea¬ 
ture  from  the  model.  In  this  case,  once  a  process  starts  executing,  it  continues  executing 
until  it  voluntarily  releases  the  CPU.  If  a  higher  priority  process  requests  execution,  it  has 
to  wait  until  the  running  process  finishes.  Non-preemptive  schedulers  usually  cause 
response  time  for  higher  priority  processes  to  be  higher.  They  are,  however,  simpler 
to  implement,  and  allow  for  simpler  programs  (for  example,  the  deadlock  problem 
described  above  does  not  exist  if  no  preemption  occurs).  Having  both  types  of  scheduler 
in  our  model  allowed  us  to  extend  our  results  to  a  larger  class  of  systems. 
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Verification  Results 

Schedulability  is  one  of  the  most  important  properties  of  a  real-time  system.  It  states  that 
no  process  will  miss  its  deadline.  In  this  example  the  deadlines  are  the  same  as  the  periods 
(except  for  the  weapon  release  subsystem).  The  following  table  summarizes  the  execution 
times  computed  by  the  algorithms.  Processes  are  shown  in  decreasing  order  of  priority. 
Deadlines  are  also  shown  so  that  schedulability  can  be  easily  checked.  Minimum  and 
maximum  execution  times  are  given  for  both  preemptive  and  non-preemptive  schedulers. 


Subsystem 

Deadline 

Exec.  Times 
Preemptive 

Exec.  Times 

Non  Preemptive 

Weapon  release 

5 

[3,3] 

[3,9] 

Radar  tracking  filter 

25 

[2,5] 

[2,10] 

RWR  contact  mgmt. 

25 

[7,10] 

[7,15] 

Data  bus  poll 

40 

[1,11] 

[1,14] 

Weapon  aim 

50 

[10,14] 

[2,18] 

Radar  target  update 

50 

[12,19] 

[12,19] 

NAV  update 

50 

[20,34] 

[20,27] 

Display  graphic 

80 

[10,44] 

[10,43] 

Display  hook  update 

80 

[14,46] 

[14,47] 

Tracking  target  update 

100 

[26,51] 

[26,51] 

Weapon  protocol 

200 

[1,21] 

[3,46] 

NAV  steering  cmds. 

200 

[35,85] 

[36,74] 

Display  store  update 

200 

[36,95] 

[37,97] 

Display  keyset 

200 

[37,96] 

[38,98] 

Display  status  update 

200 

[40,99] 

[41,101] 

Figure  30.  Aircraft  controller  schedulability  results  (times  are  in  the  form  [min, max]) 

We  can  see  from  the  table  above  that  the  process  set  is  schedulable  using  preemptive 
scheduling.  An  analysis  of  a  similar  process  set  using  RMS  showed  that  only  the  first  eight 
processes  were  guaranteed  to  meet  their  deadlines  [60].  From  our  results  we  can  also  iden- 
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tify  many  important  parameters  of  the  system.  For  example,  the  response  time  is  usually 
very  low  for  best-case  computations,  but  it  is  also  good  for  the  worst  case.  Most  processes 
take  less  than  half  their  required  time  to  execute.  This  indicates  that  the  system  is  still  not 
close  to  saturation,  although  the  total  CPU  utilization  is  high. 

Notice  also  that  preemption  does  not  have  a  big  impact  on  response  times.  Except  for  the 
most  critical  process,  all  others  maintain  their  schedulability  if  a  non-preemptive  sched¬ 
uler  is  used.  Moreover,  we  can  see  that  although  non-preemption  causes  weapon  release  to 
miss  its  deadline,  but  by  a  relatively  small  amount.  If  a  preemptive  scheduler  were  expen¬ 
sive,  reducing  the  CPU  utilization  slightly  might  make  the  complete  system  schedulable 
without  changing  the  scheduler.  By  having  such  information  the  designer  can  easily  assess 
the  impact  of  various  alternatives  to  improve  the  performance,  without  having  to  change 
the  implementation. 

As  another  example  of  how  the  designer  can  use  these  results,  we  can  analyze  the  response 
time  for  the  display  graphic  subsystem.  The  periodicity  of  this  subsystem  is  80  ms  and  a 
shorter  period  might  be  desired  to  make  motion  look  continuous.  However,  the  response 
time  of  this  process  can  be  as  high  as  44  ms.  Changing  the  period  to  40  ms  would  most 
likely  make  it  miss  its  deadline.  The  designer  may  choose  to  decrease  it  to  50  ms,  but  this 
is  still  close  to  the  response  time,  and  the  increased  load  might  make  the  system  unschedu- 
lable.  The  model  can  be  easily  changed  to  check  this  hypothesis,  but  our  analysis  shows 
that  it  is  unlikely  that  this  modification  will  preserve  schedulability. 

The  effect  of  preemption  on  execution  time  can  be  assessed  as  well.  We  have  computed 
the  maximum  and  minimum  execution  times  for  processes  after  they  have  been  granted 
the  CPU.  If  minimum  and  maximum  are  not  the  same,  the  process  can  be  preempted  after 
starting  execution.  For  example,  the  display  graphic  subsystem  can  finish  in  as  little 
as  7  ms  and  in  as  much  as  14  ms  after  it  starts  execution.  In  other  words,  preemption  over¬ 
head  can  be  as  high  as  7  ms  for  this  subsystem.  The  NAV  steering  subsystem  has  a  mini¬ 
mum  of  1  ms  and  a  maximum  of  44  ms.  This  means  that  other  processes  can  delay  it  for 
43  ms.  It  is  clear  that  NAV  steering  can  be  preempted  for  a  longer  time  than  display 
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graphic,  since  it  has  lower  priority.  Our  results,  however,  allow  us  to  determine  how  much 
longer  it  can  be  preempted.  As  an  important  variation  of  this  property,  we  can  compute  the 
priority  inversion  time  for  high  priority  processes.  This  can  help  identify  the  reasons  why 
a  system  is  not  predictable,  and  help  correct  its  behavior. 

We  examine  one  more  property  of  this  particular  model.  The  weapons  system  is  critical  to 
the  aircraft.  It  is  very  important  that  it  responds  quickly  to  the  pilot’s  command.  However, 
when  a  pilot  presses  the  firing  button,  many  subsystems  are  involved  in  identifying  and 
responding  to  this  event.  We  can  determine  its  response  time  using  the  algorithms 
described  previously.  By  computing  the  minimum  and  maximum  times  between  pressing 
the  fire  button  and  the  execution  of  the  weapon  release  process  we  are  able  to  determine  if 
the  weapon  system  responds  quickly  enough  to  satisfy  the  aircraft  requirements.  In  our 
example,  the  minimum  time  between  detecting  that  the  fire  button  has  been  depressed  and 
the  end  of  execution  of  weapon  release  is  120  ms.  The  maximum  time  is  167  ms,  not 
accounting  for  the  possibility  that  the  firing  sequence  may  be  aborted,  or  that  weapon  aim 
may  lose  contact  with  the  target.  Of  course  external  events  have  to  be  added  to  these  num¬ 
bers,  such  as  the  time  between  pressing  the  button  and  it  being  detected  by  display  keyset, 
or  the  time  it  takes  to  actually  fire  the  weapons.  But  the  designer  of  the  system  now  knows 
how  much  time  the  firing  protocol  adds  to  these  external  factors  in  the  actual  airplane. 

In  this  example  we  have  shown  that  Verus  allows  the  analysis  of  complex  realistic  sys¬ 
tems.  We  have  been  able  to  determine  the  schedulability  of  the  system  and  understand  its 
behavior  in  detail.  We  have  also  been  able  to  produce  information  about  its  behavior  that 
might  have  been  difficult  to  obtain  using  other  methods,  such  as  the  response  time  of  the 
weapons  subsystem. 
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6.3  A  Robotics  System 

One  application  of  real-time  systems  that  is  becoming  increasingly  common  is  in  robotics. 
Guaranteeing  that  tasks  are  executed  within  their  expected  deadline  is  critical  for  the 
integrity  of  a  robot  and  for  the  success  of  its  mission.  The  computation  of  quantitative 
properties  can  assist  in  validating  such  systems.  The  example  discussed  in  this  section  is 
derived  from  the  one  in  [38].  It  describes  a  real  robot  used  in  nuclear  reactors  to  measure 
the  shapes  of  pipes  by  moving  around  them  with  a  distance  sensor.  The  robot  architecture 
has  three  subsystems,  motor,  measurement  and  command.  The  motor  subsystem  controls 
the  robot  movements  and  position.  The  function  of  the  measurement  subsystem  is  to  acti¬ 
vate  and  control  the  distance  sensors.  Finally,  the  command  subsystem 
receives  commands  from  the  communication  link  and  sends  them  to  the  appropriate  tasks. 


►  Data  flow  - OControl  flow 


Figure  31.  Robot  architecture 
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Each  subsystem  consists  of  a  set  of  tasks.  The  motor  subsystem  contains  one  task, 
motorjcontrol.  Its  function  is  to  receive  data  from  sensors  in  the  servo  motors,  and  actuate 
them.  The  task  consists  of  two  subtasks,  servo_read  and  servo_control.  The  first  one  is  an 
interrupt  routine  that  reads  data  directly  from  the  physical  devices.  The  second  one  pro¬ 
cesses  these  data  and  outputs  control  signals  to  the  motors  at  a  lower  priority.  The 
measurement  subsystem  has  two  tasks,  sensor_read  and  sensor _control.  The  first  task 
reads  data  from  the  distance  sensors  and  preprocesses  it.  This  information  is  then  sent 
to  sensorjcontrol,  which  processes  it  further  and  outputs  the  results  to  a  remote  system  to 
be  analyzed.  Finally,  the  command  subsystem  also  has  two  tasks.  The  command_read  task 
receives  commands  from  the  communication  link  and  interprets  them.  It  consists  of  two 
subtasks:  an  interrupt  routine,  followed  by  a  second  subtask  that  has  a  lower  priority.  The 
final  task  of  this  subsystem  is  command _process.  Its  first  subtask  receives  the 
command  interpreted  by  command_read,  and  the  second  one  then  executes  the  command. 
Control  variables  that  are  updated  by  this  subtask  are  used  to  communicate  commands  to 
all  dther  subsystems. 

All  tasks  are  periodic,  and  their  timing  requirements  reflect  the  characteristics  of  the  envi¬ 
ronment  in  which  the  robot  works  and  the  robot’s  expected  response  time.  These  require¬ 
ments  are  summarized  in  the  table  below.  Each  task  is  presented  as  a  sequence  of 
components,  each  with  a  different  execution  time  and  priority.  A  component  may  corre¬ 
spond  to  a  subtask,  or  subtasks  may  be  split  in  more  than  one  component  due 
to  synchronization.  For  example,  the  first  components  of  boih  motor_control  and 
command_read  correspond  to  their  interrupt  routines  and  execute  at  high  priorities. 
Synchronization  accounts  for  the  other  components.  For  example,  the  last  component  of 
command  j>rocess  updates  control  variables  that  will  be  used  by  other  tasks.  Interference 
from  other  tasks  is  avoided  by  accessing  those  variables  at  a  high  priority  level.  The  other 
components  have  been  created  to  reflect  the  synchronization  pattern  between 
processes  sharing  data  (in  this  case  between  sensor_read  and  sensorjcontrol),  and 
between  commandjread  and  command _process.  Priority  inheritance  protocols  have  been 
used  to  avoid  priority  inversion  [66].  These  protocols  change  the  priority  of  the  tasks  at 
synchronization  points,  thus  dividing  the  tasks  into  components. 
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Task 

Period 

Exec.  Times 

Deadline 

Priorities 

Cl 

C2 

C3 

Pi 

P2 

P3 

Motor  control 

40 

1 

5 

- 

40 

10 

7 

- 

Sensor  read 

100 

10 

5 

5 

100 

4 

8 

4 

Sensor  control 

50 

8 

12 

- 

50 

5 

8 

- 

Command  read 

200 

10 

20 

3 

200 

9 

2 

3 

Command  process 

400 

2 

12 

10 

400 

3 

1 

6 

Figure  32.  Timing  requirements  for  aircraft  controller 

The  Analysis  of  the  Robotics  System 

Computing  response  times  for  all  processes  generated  the  results  in  the  table  below.  This 
table  shows  that  the  task  set  is  schedulable.  Moreover,  the  maximum  execution  times  of 
many  tasks  are  close  to  their  deadlines.  This  indicates  a  high  load  on  the  system;  it  is 
unlikely  that  adding  more  tasks  to  the  task  set  would  produce  a  schedulable  system.  This 
information  allows  the  designer  to  optimize  or  fine  tune  the  system. 


Task 

Deadline 

Exec,  times 

Motor  control 

40 

min 

6 

max 

16 

Sensor  read 

100 

45 

95 

Sensor  control 

50 

20 

49 

Command  read 

200 

181 

190 

Command  process 

400 

219 

223 

Figure  33.  Schedulability  analysis  for  original  system 

Using  the  results  computed  by  our  algorithms,  we  have  been  able  to  suggest  changes  to  the 
design  and  to  analyze  the  effects  of  such  changes.  In  the  original  design  sensorjread  gen- 
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crates  data  that  are  used  by  sensor_control.  However,  the  two  tasks  execute  independently 
of  one  another.  In  some  cases  sensorjcontrol  might  execute  even  if  data  are  not  yet  avail¬ 
able.  In  this  case,  sensor_control  uses  data  generated  by  the  previous  instantiation  of 
sensor_read,  which  may  be  obsolete.  We  have  changed  the  system  to  avoid  this  problem 
and  have  analyzed  the  resulting  design.  The  modification  consists  of  making  the  termina¬ 
tion  of  sensor_read  trigger  the  execution  of  sensor_control.  Care  must  be  taken,  however, 
because  the  processes  involved  have  different  periods;  sensorjread  executes  every 
100  ms,  sensor_control  executes  every  50  ms.  We  change  the  system  so  that 
sensor _read  signals  the  execution  of  sensor_control  every  100  ms,  but  sensor_control  also 
executes  independently  50  ms  after  sensorjread  runs.  In  this  case  one  instantiation  of 
sensorjcontrol  is  synchronized  with  sensor j-ead  while  the  other  is  independent.  The 
schedulability  analysis  of  the  modified  example  is  given  in  the  table: 


Task 

Deadline 

Exec,  times 

Motor  control 

40 

min 

6 

max 

16 

Sensor  read 

100 

20 

36 

Sensor  control 

50 

21 

121 

Command  read 

200 

91 

91 

Command  process 

400 

96 

296 

Figure  34.  Schedulability  analysis  for  modified  system 

The  new  design  is  not  schedulable,  since  sensorjcontrol  can  take  up  to  121  ms  to  execute. 
We  can  use  the  same  quantitative  algorithms  to  find  out  more  about  the  behavior  of  the 
system  and  to  correct  the  problem.  A  more  detailed  analysis  reveals  that  the  two  instantia¬ 
tions  of  sensorjcontrol  have  very  distinct  behaviors.  Whenever  executing  periodically 
(and  independent  of  sensorjread),  sensorjcontrol  takes  between  21  and  121  ms  to  finish. 
However,  whenever  executing  after  sensorj-ead,  it  takes  exactly  26  ms  to  execute  in  the 
modified  model.  This  shows  that  the  periodic  execution  of  sensorjcontrol  is  the  bottle¬ 
neck  of  the  system.  One  solution  to  the  problem  is  simply  removing  the  periodic  instantia- 
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tion  of  sensor_control.  This  solution  was  easily  implemented,  and  the  schedulability 
analysis  is  presented  in  table: 


Task 

Deadline 

Exec,  times 

Motor  control 

40 

min 

6 

max 

16 

Sensor  read 

100 

20 

36 

Sensor  control 

50 

26 

26 

Command  read 

200 

91 

91 

Command  process 

400 

70 

270 

Figure  35.  Schedulability  analysis  for  final  system 

The  system  is  again  schedulable,  but  now  sensor_control  executes  only  once  every 
100  ms.  Is  this  a  satisfactory  solution?  Again,  we  can  use  the  same  algorithms  to  analyze 
the  modified  design.  By  computing  the  time  between  the  end  of  the  execution  of 
sensor_read  and  the  beginning  of  sensor_control  we  can  verify  if  data  produced  by  the 
first  task  is  being  consumed  timely  by  the  second  one.  In  the  modified  model  this  time  is 
between  1  and  7  ms,  meaning  that  data  produced  by  sensor_read  are  promptly  consumed 
by  sensor_control.  Therefore  we  can  conclude  that  in  spite  of  changing  the  periodicity  of 
sensorjcontrol  we  are  still  maintaining  predictability.  The  condition  counting  algorithms 
have  also  been  useful  in  analyzing  the  performance  of  this  model.  We  have  been  able  to 
verify  how  the  old  periodicity  of  sensorjcontrol  relates  to  the  new  model.  We  can  consider 
all  execution  paths  from  the  time  sensor_read  starts  until  sensorjcontrol  finishes  as  the 
active  period  for  the  measurement  subsystem.  During  such  a  period,  how  many  times  can 
the  50  ms  time-out  occur?  In  other  words,  how  many  times  would  sensorjcontrol  be  acti¬ 
vated  using  the  original  periodicity  during  an  active  period?  The  result  is  from  1  to  3 
times.  We  conclude  that  the  modified  system  satisfies  the  original  timing  constraints,  even 
though  it  has  a  lighter  load. 
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In  this  example  we  have  been  able  to  analyze  the  behavior  of  the  robot  from  several  per- 
spectives.  We  have  determined  that  it  would  meet  its  deadlines,  but  that  it  was  inefficient. 
We  have  discussed  how  to  optimize  the  design  and  then  we  have  been  able  to  analyze  the 
performance  of  the  modified  design. 


6.4  A  Medical  Monitoring  System 

This  section  presents  a  patient  monitoring  system  derived  from  the  one  presented  in  [31]. 
It  is  a  realistic  example  that  models  many  features  existing  in  actual  systems.  The  example 
has  been  expanded  to  show  how  the  algorithms  described  in  this  paper  can  be  used  to  ana¬ 
lyze  models  of  industrial  complexity.  The  resulting  model  for  this  example  has  more  than 

10^^  states  but  its  timing  characteristics  can  be  computed  in  a  few  seconds. 

I - - 1 


Figure  36.  The  patient  monitoring  system 

The  system  consists  of  a  set  of  processes  and  can  be  seen  in  figure  36.  The  acquire  process 
is  the  only  periodic  process  in  the  system,  all  others  are  aperiodic.  Acquire  executes  every 
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20  ms,  and  its  function  is  to  read  data  from  sensors  monitoring  the  patient.  Usually,  the 
data  read  by  the  sensors  contain  spurious  information.  In  order  to  eliminate  erroneous 
Hata  the  output  of  acquire  is  sent  to  ihc  filter  process.  Filter  is  an  aperiodic  process.  It  is 
triggered  whenever  data  are  read  from  the  sensors,  that  is,  whenever  acquire  finishes  its 
execution.  The  filter  process  is  dependent  on  data  generated  by  the  acquire  process.  The 
same  dependency  pattern  is  also  used  to  trigger  execution  of  the  other  aperiodic  processes. 
After  executes,  its  results  are  analyzed  by  the  patient  condition  detection  processes. 
Filter  preprocesses  the  data  generated,  and  may  decide  to  start  the  detection  processes  or 
not,  depending  on  the  data  available.  Three  such  processes  are  modelled  in  this  example  to 
detect  abnormal  conditions  in  the  patient’s  blood  pressure,  heart  rate  and  temperature.  The 
detection  processes  can  issue  an  alarm  after  analyzing  the  data.  If  the  alarm  process  is 
executed,  it  also  starts  the  audio  process  that  generates  the  actual  alarm  signal.  Finally,  the 
filter  process  also  sends  its  data  to  the  ' display  and  recorder  processes,  that  display  the  data 
on  the  screens  and  record  it  in  some  non-volatile  media  for  future  analysis.  The  execution 
times  for  the  processes  in  the  system  can  be  summarized  as  follows.  The  acquire  process 
executes  for  1  ms,  the  filter  executes  for  3  ms,  and  all  other  processes  execute  for  2  ms. 

Most  processes  in  this  system  are  aperiodic  in  nature.  Because  of  this,  methods  such  as  the 
rate  monotonic  scheduling  [50,59,68]  cannot  be  directly  used  to  analyze  this  process  set. 
For  example,  the  assignment  of  priorities  to  processes  is  more  complex  than  in  the  peri¬ 
odic  case  which  can  use  the  RMS  algorithms.  In  this  example  priorities  have  been 
assigned  heuristically,  and  quantitative  algorithms  have  been  used  to  investigate  the  effi¬ 
ciency  of  the  assignment.  Initially,  the  priority  order  defined  was,  from  the  highest  to  the 
lowest  priority  process:  acquire,  filter,  blood_pressure,  heart_rate,  temperature,  display, 
recorder,  alarm,  and  audio. 

The  aperiodic  nature  of  the  processes  also  makes  it  difficult  to  determine  the  schedulabil- 
ity  requirements.  Except  for  the  acquire  process,  no  other  process  has  a  deadline.  Never¬ 
theless,  the  timing  constraints  of  the  system  can  be  easily  identified.  The  acquire  process 
has  a  period  and  a  deadline  of  20  ms.  The  timing  constraints  for  the  other  processes  can  be 
defined  in  several  ways.  A  straightforward  way  is  to  require  that  all  processes  to  finish 
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before  the  next  execution  of  acquire.  Our  algorithms  can  determine  if  the  process  set  satis- 
ties  this  constraint  by  computing  minimum  and  maximum  times  between  the  moment 
when  cicquivc  requests  execution  and  the  moment  when  each  process  terminates.  How¬ 
ever,  this  requirement  can  be  too  restrictive  in  some  cases.  Overlapping  the  execution  of 
consecutive  process  instantiations  is  acceptable  if  the  response  time  can  still  be  bounded. 
The  algorithms  described  in  this  paper  can  determine  response  times  for  all  processes  by 
checking  if  there  exists  a  process  that  can  execute  for  an  unbounded  amount  of  time.  If 
there  is  such  a  process,  then  the  system  is  not  schedulable.  If  not,  these  results  allow  the 
designers  to  check  if  the  response  times  are  acceptable.  Both  results  have  been  computed 
for  this  example,  and  are  presented  in  the  following  table. 


Process 

Period 

Execution  Times 

(1) 

(2) 

min 

max 

min 

max 

acquire 

20 

1 

1 

1 

1 

filter 

- 

4 

4 

3 

3 

blood  pressure 

- 

6 

OO 

2 

2 

heart  rate 

- 

6 

oo 

2 

4 

temperature 

- 

6 

OO 

2 

6 

display 

- 

6 

12 

2 

8 

recorder 

- 

8 

14 

4 

10 

alarm 

- 

12 

CO 

6 

10 

audio 

- 

14 

oo 

2 

2 

(1)  Minimum  and  mayimnm  times  between  the  start  of  acquire  and  the  end  of  execution  of  the  process.  If 
the  maximum  time  is  less  than  the  period  of  acquire,  then  the  process  will  finish  execution  before  the 
next  instantiation  of  acquire  is  started. 

(2)  Minimum  and  maximum  times  between  the  start  and  end  of  execution  of  each  process.  If  this  time  is 
less  than  infinity,  then  the  system  is  schedulable. 

Figure  37.  Response  times  for  the  original  medical  monitor 
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In  some  cases,  it  is  possible  that  the  condition  detection  processes  are  never  executed,  as 
well  as  the  alarm  and  audio  processes.  Because  of  this,  the  maximum  time  from  the  start 
of  acquire  until  these  processes  finish  is  infinity.  However,  in  many  situations  it  is  impor¬ 
tant  to  know  the  maximum  time  until  an  event  provided  it  will  occur.  We  can  change  the 
model  to  reflect  that  an  alarm  will  always  be  issued,  and  compute  such  information.  In  this 
model,  we  determined  that  from  the  moment  acquire  reads  abnormal  data  until  the  alarm 
sounds,  less  than  18  ms  will  elapse  (16  ms  for  alarm  and  18  ms  for  audio). 

The  results  produced  by  our  algorithms  can  provide  more  information  about  the  behavior 
of  the  system  than  just  determining  its  schedulability.  For  example,  we  can  see  from  the 
data  presented  that  the  alarm  and  audio  processes  are  the  ones  with  highest  response 
times.  However,  sounding  the  alarm  is  a  critical  function  that  should  not  be  postponed  by 
other  functions  such  as  recording  the  data  on  tape.  One  way  to  avoid  this  problem  is  by 
raising  the  priority  of  alarm  to  avoid  interference  from  less  important  processes  and  com¬ 
pute  the  response  times  for  the  modified  model.  We  raised  the  priority  of  the  alarm  pro¬ 
cess  by  changing  the  priority  order  to:  acquire,  filter,  alarm,  blood jrressure,  heartjrate, 
temperature,  display,  recorder,  and  audio.  The  response  times  were  computed  again,  and 
the  results  are  presented  in  the  table  below: 


Process 

Period 

Execution  Times 

(1) 

(2) 

min 

max 

min 

max 

acquire 

20 

1 

1 

1 

1 

filter 

- 

4 

4 

3 

3 

blood  pressure 

- 

6 

OO 

2 

2 

heart  rate 

- 

6 

oo 

2 

6 

temperature 

- 

6 

OO 

2 

10 

display 

- 

6 

18 

2 

14 

recorder 

- 

8 

20 

4 

16 

alarm 

- 

8 

OO 

2 

2 

audio 

- 

14 

oo 

6 

OO 
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Some  unexpected  results  can  be  seen  in  this  table.  The  system  is  no  longer  schedulable. 
The  audio  process  can  execute  for  an  unbounded  amount  of  time.  By  comparing  the  two 
tables  we  see  that  the  maximum  execution  times  of  most  processes  increased.  But  no  addi¬ 
tional  load  has  been  added  to  the  system.  In  order  to  verify  why  this  behavior  was  occur¬ 
ring  we  used  a  counterexample.  By  expressing  the  property  that  the  audio  process  would 
always  finish  execution,  we  were  able  to  produce  a  counterexample  which  showed  that 
this  property  was  false.  The  execution  trace  revealed  the  following  execution  sequence 
leading  to  the  problem: 


acquire', 

filter; 

blood _pressure; 
alarm; 
heart_rate; 

alarm; 

temperature; 

alarm; 

display; 

recorder; 

acquire; 

filter. 


We  can  see  from  the  trace  above  that  the  problem  is  caused  by  the  fact  that  alarm  executes 
three  times  for  the  same  instantiation  of  acquire  when  all  detection  processes  find  abnor¬ 
malities.  This  causes  an  overload  in  the  system  making  it  unschedulable.  The  reason  this 
did  not  happen  before  was  that  every  time  a  detection  process  triggered  the  alarm  process, 
it  requested  execution,  but  it  would  only  execute  after  all  detection  processes  executed. 
One  execution  responded  to  all  alarm  conditions.  A  simple  solution  to  this  problem  is  to 
lower  the  priority  of  alarm  and  change  the  design  so  that  multiple  alarms  are  handled  cor¬ 
rectly.  The  final  priority  order  is:  acquire,  filter,  blood_pressure,  heart_rate,  temperature. 
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alarm,  display,  recorder,  and  audio.  The  results  computed  using  this  priority  order  showed 
that  the  system  was  schedulable. 

The  condition  counting  algorithms  can  also  be  used  to  analyze  the  behavior  of  the  system. 
If  the  designer  believes  that  the  alarm  process  is  being  blocked  by  less  important  pro¬ 
cesses,  he  or  she  can  use  the  condition  counting  algorithms  to  quantify  this  effect.  For 
example,  we  can  compute  how  much  time  is  spent  on  the  execution  of  the  display  or  the 
recorder  processes  while  alarm  is  requesting  execution.  The  parameters  of  mincount  and 
maxcount  can  be  specified  as  follows.  The  initial  state  is  the  start  of  alarm,  the  final  state  is 
the  end  of  execution  of  alarm,  and  the  condition  to  be  counted  is  the  processor  granted  to 
either  display  or  recorder.  Using  the  first  priority  order  presented,  the  time  spent  on  dis¬ 
play  and  recorder  while  alarm  is  blocked  is  4  ms.  With  the  last  priority  order  this  time  is 
zero,  as  expected. 


6.5  The  PCI  Local  Bus 

The  PCI  Local  Bus  [45,46]  is  a  high  performance  bus  architecture  that  can  have  a  data 
width  of  32  or  64  bits.  It  has  been  designed  by  Intel  to  be  used  in  its  latest  family  of  pro¬ 
cessors.  Intel’s  goal  is  to  offer  a  fast  bus  design  at  low  cost  that  will  accommodate  current 
as  well  as  future  systems.  PCI  buses  can  be  found  in  systems  based  on  Alpha,  Pentium  and 
Pentium  Pro  processors.  The  majority  of  Pentium  based  systems  manufactured  today 
employ  the  PCI  bus. 

A  typical  PCI  system  can  be  seen  below.  The  most  important  subsystems  connected  to  the 
bus  are  the  processor,  a  video  controller,  a  SCSI  controller,  and  an  ISA  bridge  controller, 
which  connects  the  PCI  bus  to  a  slower  ISA  bus.  Modems,  floppy  disk  controllers  and 
other  low  speed  components  are  connected  to  the  ISA  bus.  Main  memory  and  the  second¬ 
ary  cache  are  connected  directly  to  the  processor  using  a  PCI-memory-processor  bridge. 
Other  components  can  be  added  to  the  system.  Usually  expansion  slots  are  provided  for 
this  purpose. 
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Figure  38.  The  PCI  local  bus 


Each  of  the  subsystems  shown  above  is  allowed  to  request  access  to  the  bus  and  issue 
transactions.  Slave  subsystems  are  also  supported;  such  subsystems  respond  to  transac¬ 
tions,  but  do  not  issue  them.  A  simplified  PCI  transaction  is  shown  in  the  figure  below. 
The  request  for  a  transaction  starts  when  a  subsystem  asserts  its  request  line  REQ.  It  then 
waits  until  being  granted  the  bus  by  the  arbitration  subsystem,  which  is  indicated  by  the 
assertion  of  the  GNT  line.  This  phase  is  known  as  the  arbitration  phase.  The  next  phase  is 
the  bus  acquisition  phase.  The  bus  might  not  be  idle  when  the  new  master  is  determined 
because  the  previous  transaction  may  still  be  transferring  data.  Another  transaction  cannot 
be  issued  before  all  data  has  been  transferred.  The  bus  is  idle  whenever  both  signals 
FRAME  and  IRDY  are  deasserted  in  the  same  cycle,  giving  access  of  the  bus  to  the  new 
master.  At  this  point  the  master  asserts  the  FRAME  signal,  indicating  the  end  of  the  bus 
acquisition  phase  and  the  beginning  of  a  transaction.  It  also  has  to  assert  the  signal  IRDY, 
meaning  that  it  is  ready  to  send  (or  receive)  data.  The  bus  master  has  to  wait  for  the  target 
subsystem  to  respond  by  asserting  its  TRDY  signal.  This  indicates  that  the  target  is  ready 
to  supply  (or  receive)  data.  The  time  interval  between  the  start  of  a  transaction  and  the 
assertion  of  the  TRDY  signal  is  called  the  target  response  phase.  Data  transfer  starts  when 
both  IRDY  and  TRDY  are  asserted.  One  clock  cycle  before  the  end  of  the  data  transfer 
phase  the  FRAME  signal  is  deasserted.  At  the  next  cycle  both  IRDY  and  TRDY  are  deas- 
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serted,  and  the  bus  becomes  idle.  In  addition,  transactions  can  be  cancelled  in  various  situ¬ 
ations.  This  feature  of  the  protocol  is  discussed  in  more  detail  later. 
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Figure  39.  A  transaction  in  the  PCI  Bus 

Arbitration  in  the  PCI  bus  is  implemented  by  a  two  phase  arbiter  as  seen  in  the  next  fig¬ 
ure.  Each  arbiter  bank  chooses  among  its  incoming  requests,  and  sends  its  decision  to  the 
following  bank.  The  output  of  bank2  will  be  the  new  bus  master.  The  decision  is  based 
on  the  policy  signal,  which  can  be  set  to  fixed  priority  or  round-robin.  If  all  policies  are 
set  to  the  same  value,  the  global  arbitration  policy  will  be  either  fixed  priority  or  round- 
robin.  However,  mixed  arbitration  policies  are  possible  by  combining  different  policies  in 
the  banks.  Our  model  for  the  PCI  bus  follows  the  description  above.  Arbitration  policies 
can  be  set  to  any  possible  combination,  allowing  mixed  arbitration  policies.  However,  in 
our  model  we  must  make  some  restrictions  to  the  protocol  described.  For  example,  we 
must  restrict  the  amount  of  data  being  transferred  in  one  transaction.  If  this  restriction  is 
not  implemented,  no  bounds  on  response  time  can  be  determined.  In  our  model  a  single 
transaction  can  transfer  between  1  and  16  cache  lines  of  data.  Our  analysis  will  show  how 
the  information  generated  by  this  model  can  be  used  to  determine  the  response  time  for 
models  without  this  restriction.  A  similar  approach  has  to  be  taken  with  the  possibility  of 
cancelling  an  ongoing  transaction.  Again,  in  order  to  prevent  starvation,  we  must  bound 
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the  number  of  times  a  transaction  may  be  cancelled.  Our  final  model  for  the  PCI  bus  has 
lO”^  reachable  states  out  of  a  state  space  of  10^*  states.  The  transition  relation  uses  less 
than  10,000  BDD  nodes,  and  the  verification  was  completed  in  minutes. 


Figure  40.  The  PCI  arbiter 

Verification  and  Performance  Analysis  of  the  PCI  Bus 

Our  analysis  concentrates  on  the  verification  of  issues  such  as  transaction  termination  and 
arbitration  fairness  as  well  as  on  transaction  performance.  Being  able  to  estimate  the 
response  time  of  a  transaction  is  extremely  important  in  any  bus  design,  especially  in  one 
which  has  high  performance  a  primary  goal.  The  bus  data  transfer  rate  and  the  overhead 
imposed  by  arbitration  and  communication  protocols  are  examples  of  parameters  involved 
in  such  an  analysis.  If  those  parameters  cannot  be  determined,  it  will  not  be  possible  to 
design  an  optimized  system  that  fully  utilizes  the  available  resources. 

Moreover,  the  PCI  bus  is  a  good  alternative  for  critical  applications  in  which  a  bounded 
response  time  is  vital.  However,  if  the  worst  case  response  time  of  a  transaction  in  the  PCI 
bus  hasn’t  been  specified,  such  applications  will  most  likely  be  implemented  using  other 
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bus  architectures.  By  bounding  the  worst  time  response  of  a  transaction  we  hope  to  help 
application  designers  to  evaluate  the  use  of  the  PCI  bus  more  accurately. 

The  correctness  of  the  PCI  bus  protocol  can  be  verified  using  the  CTL  model  checker.  For 
example,  absence  of  starvation  for  bus  access  and  transaction  termination  can  be  verified 
by  the  following  formulas: 

AG  (REQ  -»  AF  GNT) 

AG  (start_transaction  AF  end_transaction) 

The  properties  above  show  that  the  response  time  of  PCI  transactions  is  bounded,  but  they 
give  no  indication  of  their  performance.  We  will  use  the  quantitative  algorithms  described 
to  determine  the  response  time  for  transactions.  The  results  of  our  quantitative  analysis 
also  determine  the  correcmess  of  the  algorithm,  for  example,  a  transaction  always  finishes 
if  its  maximum  response  time  is  less  than  infinity. 

In  our  performance  analysis  we  will  follow  the  structure  of  the  protocol  by  computing  the 
response  time  for  each  phase  of  the  transaction  separately.  In  this  way  we  can  have  a  better 
understanding  of  the  behavior  of  the  protocol.  By  computing  the  latency  of  each  phase  we 
are  able  to  assert  the  efficiency  of  each  step  in  the  protocol  and  obtain  the  global  behavior 
by  adding  individual  figures.  Results  will  be  grouped  into  two  categories,  total  bus  acqui¬ 
sition  latency  and  total  transaction  latency.  The  first  category  corresponds  to  the  total  time 
between  a  request  being  made  on  the  bus  and  the  subsystem  actually  being  able  to  use  the 
bus.  The  second  category  represents  the  total  usage  of  the  bus,  that  is,  the  time  between 
asserting  the  FRAME  signal  until  the  end  of  data  transfer.  The  table  below  shows  the 
response  times  when  the  arbitration  policy  is  set  to  round-robin  in  all  banks  and  transac¬ 
tion  cancelling  is  not  allowed.  Notice  that  in  all  cases  discussed  in  this  paper  the  latency 
for  the  data  transfer  phase  varies  between  1  and  16  clock  cycles,  there  is  no  overhead  asso¬ 
ciated  with  it.  For  that  reason,  this  column  will  not  be  shown  in  the  tables. 
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Figure  41 .  Response  times  for  global  round-robin  policy 

From  the  table  above  we  can  see  two  interesting  properties  of  the  system.  The  total  trans¬ 
action  latency  is  at  most  18  clock  cycles,  and  in  this  case  16  clock  cycles  of  data  are  trans¬ 
mitted.  This  means  that  once  a  master  is  able  to  use  the  bus,  it  can  send  data  very 
efficiently.  Another  characteristic  of  the  protocol  is  reflected  on  the  bus  acquisition  times. 
The  maximum  of  18  cycles  corresponds  to  one  transaction.  After  being  granted  the  bus  the 
new  master  may  have  to  wait  for  at  most  one  more  transaction  to  complete.  This  shows 
that  once  the  bus  is  granted  to  a  master,  it  will  not  be  granted  to  another  before  the  first  one 
issues  its  transaction.  Therefore  no  starvation  can  occur  after  a  master  is  granted  the  bus. 
This  property  can  be  verified  by  the  following  CTL  formula: 

AG  (GNT  A[GNT  U  FRAME]) 

A  more  intriguing  result  can  be  seen  in  the  arbitration  latency  results.  The  first  two  sub¬ 
systems  can  take  almost  twice  as  long  to  access  the  bus  as  the  others.  In  a  round-robin 
environment,  all  subsystems  should  be  granted  equal  usage  of  the  resource,  but  this  is  not 
true  in  our  example.  By  analyzing  the  execution  traces  produced  by  our  tools  we  are  able 
to  determine  the  reason  for  the  unfair  access  to  the  bus.  The  problem  arises  from  the  con¬ 
nection  of  the  request  lines  to  the  arbiter  as  seen  below.  The  ISA  bridge  and  the  SCSI  con¬ 
troller  are  connected  together  to  bankO,  while  the  video  and  the  processor  subsystems  are 
alone  in  their  banks.  If  bus  traffic  is  high,  the  ISA  bridge  and  the  SCSI  subsystems  may 
have  to  wait  for  the  one  another  before  their  request  reaches  bank2.  Subsequently  they 
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may  have  to  wait  for  subsystems  connected  to  the  other  banks  to  execute  before  being 
granted  the  bus.  In  other  words,  they  compete  in  both  levels  of  arbitration,  while  the  other 
subsystems  only  compete  in  the  last  level.  This  causes  the  worst  time  latency  to  be  approx¬ 
imately  twice  as  long  for  these  subsystems.  We  can  conclude  from  these  results  that  two 
level  arbitration  may  have  a  different  behavior  than  an  equivalent  one  level  arbiter.  In  this 
case  the  problem  is  caused  by  an  asymmetric  connection  of  request  lines. 


Figure  42.  Connections  of  request  lines  to  the  arbiter 

We  can  also  use  these  results  to  analyze  the  overhead  imposed  by  the  communication  pro¬ 
tocol  on  the  transaction  time.  We  have  already  seen  that  after  asserting  the  FRAME  signal 
there  is  an  overhead  of  2  clock  cycles.  This  overhead  is  independent  of  the  transfer  size.  If 
a  transaction  is  allowed  to  transfer  more  than  16  cache  lines  of  data  at  once,  the  total  utili¬ 
zation  of  the  bus  will  increase.  The  designers  of  the  bus  can  use  this  information  to  deter¬ 
mine  which  is  the  best  transfer  size  for  a  given  system.  The  following  two  formulas  have 
been  used  to  verify  the  above  statements: 

AG  (FRAME  ^  AF<  2  (state  =  DATA_TRAJSrSFER)) 

AG  ((state  =  DATA_TRANSFER) 

A[state  =  DATA_TRANSFER  U  end_transaction]) 
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The  first  formula  states  that  at  most  two  cycles  after  the  transaction  starts,  it  will  enter  the 
data  transfer  phase.  The  second  formula  states  that  once  a  transaction  is  in  the  data  transfer 
phase,  it  will  continue  in  this  phase  until  its  end. 

The  overhead  associated  with  arbitration  can  be  computed  in  a  similar  way.  It  is  more 
complex,  however,  because  the  arbitration  latency  depends  not  only  on  the  transaction 
time,  but  also  on  the  number  of  active  request  lines.  We  use  the  condition  counting  algo¬ 
rithms  to  uncover  more  details  about  this  problem.  We  compute  the  number  of  transactions 
issued  on  the  bus  between  the  time  a  master  requests  access  and  the  time  it  is  granted  the 
bus.  Up  to  5  transactions  can  be  issued  during  this  period  for  the  ISA  bridge  and  the  SCSI 
subsystems,  and  up  to  2  transactions  can  be  issued  for  the  video  and  processor  subsystems. 
Total  transaction  time  for  each  of  these  intermediate  transactions  is  18  clock  cycles.  By 
comparing  the  total  effective  data  transfer  time  with  the  maximum  arbitration  time,  we  can 
see  that  each  intermediate  transaction  has  an  arbitration  time  of  one  clock  cycle.  These 
results  are  also  valid  for  the  video  and  processor  subsystems.  We  can  conclude  that  the 
arbitration  latency  can  be  computed  by  the  formula: 

Arbitration_Latency  =  n*  {TransactionJLatency  +1), 

where  n  is  the  maximum  number  of  intermediate  transactions  that  can  be  issued  between  a 
request  and  the  corresponding  grant  (computed  with  the  condition  counting  algorithms). 
This  formula  does  not  depend  on  maximum  data  transfer  size. 

The  above  results  assume  a  global  round-robin  policy.  The  behavior  of  the  system  under  a 
fixed  priority  arbitration  policy  has  also  been  studied.  The  ISA  bridge  is  the  highest  prior¬ 
ity  subsystem  on  the  bus.  Its  response  time  is  much  lower  in  the  fixed  priority  configura¬ 
tion  than  in  the  round-robin  one.  However,  all  other  subsystems  may  starve,  since  the  ISA 
bridge  can  continuously  issue  transactions.  Notice  that  only  the  arbitration  time,  but  not 
the  transaction  time,  is  affected  by  the  arbitration  policy.  These  response  times  can  be  used 
by  the  designer  to  check  if  the  performance  of  the  PCI  bus  is  adequate  for  a  critical  appli¬ 
cation.  Other  combinations  of  arbitration  policies  are  possible,  but  are  not  presented  here 
for  the  sake  of  brevity. 
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Figure  43.  Response  times  for  global  fixed  priority  policy 


The  model  described  above  allows  a  detailed  analysis  of  the  behavior  of  the  PCI  bus  pro¬ 
tocol.  Some  features  of  the  actual  bus,  such  as  parity  or  data  width,  have  been  abstracted 
from  our  model,  since  they  do  not  affect  the  timing  of  transactions.  However,  there  are 
other  features  that  do  affect  timing  such  as  the  possibility  of  a  transaction  being  cancelled. 
Errors  on  the  bus  may  occur,  the  target  may  be  slow,  or  unable  to  produce  the  data.  For 
example,  a  transaction  requesting  data  from  the  ISA  bus  will  most  likely  experience  a  long 
delay,  simply  because  of  the  relative  speeds  of  the  ISA  and  PCI  buses.  In  the  model 
described  above  this  feature  has  been  abstracted  out  by  the  assumption  that  the  target  of  a 
transaction  responds  immediately.  A  more  realistic  model  that  allows  transactions  to  be 
cancelled  has  also  been  implemented. 

In  order  to  account  for  long  delay  responses  and  aborted  transactions  we  introduce  the 
concept  of  transaction  cancellation  in  our  model.  Transactions  may  be  cancelled  any  time 
they  are  in  progress.  Transaction  cancellations  model  the  fact  that  in  the  actual  PCI  bus 
whenever  a  target  is  unable  to  answer  for  a  long  time,  it  aborts  the  transaction,  which  is 
reissued  later.  We  model  this  situation  by  cancelling  the  transaction  and  restarting  it  imme¬ 
diately  by  issuing  another  request.  However,  reissuing  the  transaction  immediately  would 
not  correctly  model  the  response  time  of  a  very  slow  target.  To  accommodate  this  situa¬ 
tion,  in  our  model  a  cancelled  transaction  is  restarted  as  many  times  as  necessary  to 
accommodate  the  target  response  time.  Using  the  algorithms  described  we  compute  the 
overhead  caused  by  cancelling  and  restarting  a  transaction,  and  use  this  result  to  determine 
the  number  of  retries  for  the  response  delay  of  a  given  target. 
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Moreover,  unlimited  cancellations  may  cause  starvation.  Therefore,  in  order  to  compute 
the  worst  time  response,  we  must  limit  the  number  of  cancellations  allowed.  A  cancella¬ 
tion  brings  the  bus  to  the  idle  state,  as  can  be  verified  by  the  following  CTL  formula; 

AG  (ABORT  ^  AX  BUS_IDLE) 

As  a  consequence,  consecutive  cancellations  have  the  same  behavior,  because  a  cancella¬ 
tion  brings  the  system  into  the  same  state  as  before  the  transaction.  Therefore,  the  total 
overhead  caused  by  n  cancellations  is  n  times  the  overhead  of  a  single  cancellation.  There¬ 
fore,  it  suffices  to  consider  the  situation  in  which  at  most  one  cancellation  occurs.  The 
results  for  a  global  round-robin  arbitration  policy  in  the  presence  of  at  most  one  transac¬ 
tion  cancellation  are  presented  below. 
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Figure  44.  Response  times  for  global  round-robin  policy,  maximum  one  cancel 


In  this  table  we  can  see  that  arbitration  latency  is  not  affected  by  transaction  cancellations. 
The  reason  is  that  whenever  a  transaction  is  cancelled  the  current  bus  master  releases  the 
bus  and  becomes  last  in  the  round-robin  queue.  On  the  other  hand,  total  transaction 
latency  increases  significantly.  The  execution  trace  of  the  transaction  with  the  worst 
latency  shows  the  following  sequence  of  events  (for  the  ISA  bridge  subsystem): 

•  A  transaction  starts  but  is  cancelled  just  before  completion,  after  17  clock  cycles. 

•  Another  request  is  made  to  complete  it  in  the  next  cycle  (one  extra  clock  cycle). 

•  An  arbitration  sequence  of  79  cycles  follows. 
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•  A  bus  acquisition  phase  starts  and  takes  17  clock  cycles. 

•  The  transaction  starts  again,  completing  after  18  cycles. 

The  arbitration  sequence  appearing  in  item  3  is  the  same  as  in  the  worst  case,  except  that 
the  request  is  made  when  the  bus  is  already  idle  because  of  the  cancellation.  The  differ¬ 
ence  of  16  clock  cycles  corresponds  to  one  maximum  data  transfer  phase  done  by  another 
bus  master,  as  shown  by  the  counterexample  for  the  worst  case  arbitration  latency  (not 
presented  for  brevity).  The  total  delay  caused  by  the  first  three  items  is  the  equivalent  of  a 
worst  case  arbitration  latency  plus  two  clock  cycles,  caused  by  the  cancellation.  A  bus 
acquisition  phase  and  a  transaction  latency  phase,  in  which  no  cancellation  occurs, 
account  for  the  last  35  cycles.  We  can  see  then  that  the  overhead  imposed  by  a  transaction 
cancellation  consists  of  a  worst  case  arbitration  latency,  a  maximum  bus  acquisition  phase, 
a  maximum  transaction  latency  (without  cancellations)  and  one  extra  clock  cycle.  Again, 
this  formula  applies  for  the  video  and  processor  subsystems.  These  results  may  be  used  to 
estimate  the  performance  of  an  implementation  of  the  PCI  in  the  presence  of  transaction 
aborts.  The  formula  derived  gives  the  overhead  for  one  transaction  cancellation,  and  can 
be  extended  to  many  cancellations  as  well.  In  this  manner,  the  worst  response  time  in  var¬ 
ious  configurations  of  the  system  can  be  computed. 

To  summarize  the  results  of  our  analysis,  we  have  been  able  to: 

•  Model  the  PCI  Local  bus  protocol  and  verify  its  correctness.  In  the  round-robin  case  no 
starvation  of  subsystems  occur,  and  transactions  always  finish,  even  in  the  presence  of 
limited  cancellations. 

•  Determine  the  minimum  and  maximum  latencies  for  each  phase  of  the  protocol,  and 
show  which  phases  are  affected  by  changes  in  the  parameters  (such  as  arbitration  policy 
and  presence  of  cancellations). 

•  Compute  response  times  independent  of  specific  values  for  the  data  transfer  phase. 

•  Determine  response  time  in  the  presence  of  limited  transaction  aborts  using  the  condi¬ 
tion  counting  algorithms  described. 
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These  results  allow  the  designers  of  the  protocol  to  understand  its  actual  behavior  and  how 
this  behavior  changes  when  parameters  of  the  system  are  modified.  We  believe  that  this  is 
valuable  information  when  verifying  and  optimizing  a  new  hardware  system.  This  exam¬ 
ple  shows  that  our  method  can  be  used  to  analyze  the  performance  of  modem  hardware 
designs  that  have  very  complex  behavior. 


6.6  A  Distributed  Real-Time  System 

In  this  section  we  analyze  a  distributed  real-time  system.  This  is  a  complex  and  realistic 
application,  its  components  are  existing  systems  and  protocols  that  are  actually  used  in 
many  real  situations.  The  example  consists  of  three  main  components,  a  FDDI  network,  a 
multiprocessor  connected  to  this  network  and  one  of  the  processors  in  the  multiprocessor, 
the  control  processor. 

The  FDDI  network  is  a  lOOMb/s  local/metropolitan  area  network  that  uses  a  token  ring 
topology  [4].  It  has  gained  popularity  recently,  particularly  in  real-time  applications,  since 
it  allows  communication  time  to  be  bounded.  There  are  several  stations  connected  to  the 
network  in  the  system.  They  generate  multimedia  and  sensor  data  sent  to  the  control  pro¬ 
cessor,  as  well  as  additional  traffic  inside  the  network.  There  is  a  deadline  of  100  ms 
between  the  generation  of  multimedia  data  and  its  processing  by  the  control  processor. 

The  traffic  in  the  network  has  been  modeled  as  proposed  in  [69].  Under  this  protocol,  sta¬ 
tions  choose  a  target  token  rotation  time  (TTRT).  Each  station  is  then  allocated  a  synchro¬ 
nous  capacity  such  that  if  all  stations  use  all  their  synchronous  bandwidth,  the  token 
returns  to  a  station  at  most  2  *  7TRT  time  units  after  leaving  it  [69].  In  this  example  the 
TTRT  is  8.  Traffic  is  modeled  such  that  every  16  units  (2  *  TTRT)  the  stations  utilize  the 
network  as  follows:  video  station,  6  units;  audio  station,  1  unit;  and  remainder  network 
traffic,  8  units  (in  this  example  we  will  analyze  only  the  behavior  of  video  and  audio. 
Therefore  all  the  remaining  traffic  in  the  network  has  been  grouped  together). 
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Sensors  Audio  Video 


Figure  45.  Distributed  System  Architecture 

In  the  multiprocessor,  four  active  processors  are  connected  through  a  Futurebus+  [44]- 
The  first  is  the  network  interface,  it  receives  data  from  the  network  and  sends  it  to  the  con¬ 
trol  processor.  The  network  interface  uses  the  bus  for  7  ms  at  each  time.  A  sensor  proces¬ 
sor  reads  data  from  sensors  every  40  ms.  It  buffers  the  data  and  sends  it  once  every  four 
readings  to  the  tracking  processor.  The  tracking  processor  processes  the  data  and  sends  it 
to  the  control  processor.  Both  sensor  and  tracking  data  use  the  bus  for  3  ms  each.  The 
deadline  for  sensor  data  to  be  processed  is  785  ms.  Access  to  the  bus  is  granted  using  pri¬ 
ority  scheduling.  Priorities  are  assigned  according  to  the  rate-monotonic  scheduling  the¬ 
ory,  processors  with  shorter  periods  have  higher  priority. 

In  the  control  processor  there  are  several  periodic  tasks.  The  timing  requirements  for  these 
tasks  can  be  seen  in  figure  46.  Priority  scheduling  is  also  used  in  the  control  processor, 
with  priorities  assigned  by  the  rate-monotonic  theory.  Two  of  the  tasks  in  the  control  pro¬ 
cessor  have  special  functions,  T3  processes  sensor  data,  and  t5  processes  multimedia  data. 
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Figure  46.  Timing  requirements  for  tasks  in  the  control  processor  (times  in  ms) 

Each  of  the  components  of  the  system  (FDDI,  network  and  control  processor)  has  been 
implemented  separately.  No  data  is  actually  exchanged  between  the  components  in  the 
model.  Data  have  been  abstracted  out  of  the  model,  because  data  dependencies  would  sig¬ 
nificantly  increase  the  size  of  the  model  and  the  complexity  of  verification. 

However,  while  simplifying  verification,  abstractions  can  also  introduce  invalid  execution 
sequences.  The  constraints  imposed  by  data  dependencies  significantly  reduce  the  number 
of  execution  sequences  that  can  actually  be  reached.  In  an  abstract  model  such  dependen¬ 
cies  do  not  exist.  In  this  example,  selective  quantitative  analysis  has  been  used  to  ensure 
that  only  execution  sequences  that  are  valid  have  been  considered  during  verification. 

The  first  deadline  to  be  checked  is  the  deadline  of  100  ms  between  the  generation  of  mul¬ 
timedia  data  (signaled  by  variable  video .  start)  and  its  processing  in  the  control  pro¬ 
cessor  by  process  T5  (signaled  by  variable  t5. finish).  Ideally,  we  would  like  to 
compute  these  time  bounds  using  MIN{MAX}  [video .  start ,  t5 .  finish] .  How¬ 
ever,  since  in  our  model  we  have  abstracted  out  synchronization  between  tasks,  this  would 
consider  paths  in  the  model  in  which  t5  finishes  executing  just  after  video,  without 
going  through  the  network  interface.  This  execution  sequence  corresponds  to  t5  process¬ 
ing  data  generated  by  previous  instantiations  of  video. 
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In  order  to  identify  the  valid  paths  in  the  model,  we  have  computed  the  same  time  bounds 
as  before,  but  now  considering  only  paths  that  satisfy  the  constraint  F  inter¬ 
face  .  finish.  Unfortunately,  this  is  still  not  accurate  enough,  as  it  allows  for  execution 
sequences  in  which  interface  executes  before  video  finishes,  or  after  t5  starts.  The 
actual  formula  used  to  characterize  the  correct  paths  is 

F  (video. finish  &&  F  (interface . finish  &&  F  t5. start)) 

This  formula  guarantees  that  the  events  video. finish,  interface . finish  and 
t5  .  start  must  occur,  and  in  that  order.  Moreover,  by  using  bounded  selective  quantita¬ 
tive  analysis  we  also  guarantee  that  these  events  must  happen  after  video .  start  and 
before  1 5. finish.  We  are  then  able  to  eliminate  from  consideration  all  false  paths 
introduced  in  the  model,  and  determine  the  correct  response  times. 

Using  this  formula  for  computing  the  time  between  video,  start  and  t5  .  finish 
resulted  in  the  interval  [24,  96],  that  is,  the  video  traffic  is  schedulable.  The  audio  traffic 
has  been  analyzed  in  a  similar  way,  and  will  not  be  presented  here  for  brevity.  The 
response  time  for  the  audio  station  is  in  the  interval  [16, 96]. 

This  analysis  also  uncovered  an  ambiguity  in  the  system  description.  Initially,  we  assumed 
that  process  X2  processed  the  multimedia  traffic  in  the  control  processor.  In  the  original 
description  this  point  is  not  clear.  However,  the  same  analysis  using  X2  instead  of  T5  pro¬ 
duces  the  interval  [100,  148],  which  is  clearly  not  schedulable.  Discussions  with  the 
authors  of  the  original  paper  then  clarified  the  issue,  and  in  the  model  we  introduced  pro¬ 
cess  T5  to  handle  multimedia  traffic. 

Finally,  we  must  check  the  deadline  between  a  sensor  reading  in  the  sensor  processor  and 
the  processing  of  the  data  by  in  the  control  processor.  This  deadline  is  785  ms.  In  order 
to  determine  how  long  it  takes  for  data  to  go  from  the  sensor  processor  to  the  control  pro¬ 
cessor  we  must  use  a  similar  approach  to  the  one  described.  The  direct  computation  of 
MIN{MAX}  [  sensor_obseirvation,  t3  .  finish]  searches  on  paths  in  which  data 
does  not  have  time  to  go  through  all  the  steps  in  the  protocol. 
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We  must,  therefore,  compute  this  time  provided  that  a  LTL  formula  describing  the  correct 
data  path  is  satisfied.  The  formula  that  must  be  satisfied  in  this  case  is 

F  (sensor . finish  &&  F  (track. start  && 

F  (track. finish  &&  F  tS.start))) 

By  using  this  formula  we  have  obtained  the  time  between  sensor  observation  and  T3  pro¬ 
cessing  to  be  in  the  interval  [197, 563],  well  within  the  deadline.  However,  by  looking  into 
the  design  we  noticed  a  potential  source  for  inefficiencies  in  the  Futurebus.  A  counterex¬ 
ample  for  the  longest  response  time  confirmed  our  speculations. 

In  this  system  both  sensor  and  tracking  processors  access  the  bus  periodically,  sending 
data  every  160  ms.  In  the  counterexample,  however,  data  required  two  periods  of  160  ms 
to  reach  the  control  processor.  It  was  sent  by  the  sensor  processor  to  the  tracking  proces¬ 
sor,  but  this  processor  would  only  send  it  to  the  control  processor  in  the  next  period. 
Before  this  time,  data  was  blocked  at  the  tracking  processor  because  of  its  periodicity.  Fur¬ 
ther  investigation  of  the  model  showed  that  this  was  caused  by  the  priority  order  in  which 
processors  accessed  the  bus.  The  tracking  processor  had  a  higher  priority  than  the  sensor 
processor.  This  means  that  when  the  sensor  processor  sends  data  to  the  tracking  processor, 
it  had  already  used  the  bus  for  this  period,  and  would  only  request  access  again  in  160  ms. 

The  rate-monotonic  theory  was  used  to  assign  priorities  to  bus  requests,  and  it  states  that 
shorter  periods  have  higher  priorities.  In  this  case  however,  both  processors  have  the  same 
period,  and  their  relative  priority  is  irrelevant  (from  the  rate-monotonic  perspective).  From 
the  data  transfer  pattern,  though,  it  seemed  that  exchanging  the  order  of  these  two  proces¬ 
sors  would  yield  a  better  result.  We  modified  the  design  by  changing  the  priorities,  and  the 
response  time  became  [37, 403],  an  improvement  of  almost  50%  in  the  response  time. 

Moreover,  we  have  been  able  to  compare  the  performance  of  both  designs  using  interval 
model  checking.  A  very  serious  problem  with  real-time  systems  is  priority-inversion.  It 
occurs  when  high-priority  tasks  are  blocked  by  low  priority  ones.  This  can  happen  even 
with  priority  scheduling,  in  most  cases  caused  by  synchronization.  Determining  the  exist- 
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ence  of  priority  inversion  is  extremely  important  in  the  analysis  of  real-time  systems.  In 
our  example  we  have  been  able  to  check  this  parameter  using  interval  model  checking. 

We  want  to  determine  the  existence  of  priority  inversion  between  the  time  the  sensor  pro¬ 
duces  data  until  the  time  the  tracking  processor  processes  it.  Priority  inversion  occurs  in 
this  interval  if  the  bus  is  idle  or  the  lower  priority  process  is  executing.  The  lower  priority 
process  is  either  the  sensor  or  tracking  processor,  depending  on  the  priority  order.  In  both 
cases  the  network  interface  has  higher  priority,  because  it  has  a  shorter  period. 

Using  interval  model  checking  we  have  been  able  to  check  the  LTL  formula 
G  !  (bus_idle  |  |  bus_granted  =  lower_priority)  on  the  intervals  between 
the  sensor  processor  finishing  sending  data  and  the  tracking  processor  sending  its  data  to 
the  control  processor.  The  original  design  showed  the  existence  of  priority  inversion,  as 
expected.  In  the  modified  design,  on  the  other  hand,  the  formula  above  is  true  in  all  inter¬ 
vals  under  consideration,  even  though  it  is  clearly  false  outside  these  intervals.  This  shows 
that  the  modified  design  is  optimal  with  respect  to  the  prioritized  utilization  of  the  bus. 

The  modified  design  has  a  better  response  time,  and  is  clearly  preferred  in  this  application. 
But  in  other  applications  this  might  not  be  true.  There  might  be  cases,  for  example,  in 
which  the  tracking  processor  sends  data  to  the  sensor  processor.  In  those  cases  the  modi¬ 
fied  design  is  worse  than  the  original  one.  This  again  shows  how  selective  quantitative 
analysis  and  interval  model  checking  can  be  used  to  analyze  the  different  facets  of  a  sys¬ 
tem.  The  designer  can  choose  to  optimize  the  behavior  of  a  critical  application,  even  if  at 
the  expense  of  less  critical  ones.  It  would  be  easy  to  adapt  this  analysis  to  different  data 
patterns,  and  optimize  the  response  time  for  any  other  application.  In  this  example  we  con¬ 
sidered  the  data  path  from  the  sensor  to  the  control  as  the  most  important  one. 

This  example  shows  how  the  proposed  method  can  assist  in  understanding  the  behavior  of 
complex  systems.  We  have  been  able  not  only  to  check  properties  of  the  whole  system,  but 
also  to  analyze  specific  execution  sequences  of  interest.  This  allowed  us  to  uncover  subtle¬ 
ties  about  the  application  that  might  have  been  very  difficult  to  discover  otherwise. 
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This  work  presents  a  new  method  for  specifying  and  verifying  real-time  systems.  The  sys¬ 
tem  being  verified  is  specified  in  the  Verus  language  and  then  compiled  into  a  state-transi¬ 
tion  graph.  Algorithms  derived  from  symbolic  model  checking  are  used  to  compute 
quantitative  timing  information  about  the  model.  There  are  several  advantages  to  the  new 
approach.  For  example,  the  Verus  language  has  been  especially  designed  to  allow  a 
straightforward  description  of  the  temporal  characteristics  of  programs,  simplifying  the 
expression  of  real-time  systems  in  general.  Also,  the  quantitative  information  produced  by 
the  verification  algorithms  not  only  allows  the  designer  to  check  for  its  temporal  and  func¬ 
tional  correctness,  but  also  provides  insight  into  how  well  the  system  works,  or  how  seri¬ 
ously  it  fails.  The  algorithms  presented  generate  more  detailed  information  about  the 
behavior  of  a  system  than  previous  methods  and  can  be  used  in  several  different  ways  to 
analyze  a  real-time  system. 

The  method  has  been  applied  to  several  actual  systems,  and,  in  each  case,  we  have  been 
able  to  produce  useful  information  that  can  enable  the  designers  to  understand  the  behav¬ 
ior  better  and  to  improve  the  system.  These  examples  demonstrate  the  versatility  and 
power  of  the  method,  and  can  be  used  to  emphasize  important  aspects  of  the  Verus 
approach: 
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•  The  priority  inversion  example  has  demonstrated  that  the  synchronous  composition 
model  used  in  Verus  does  not  restrict  the  applicability  or  expressive  power  of  the  tool.  It 
may  be  argued  that  some  applications  are  inherently  asynchronous,  and  therefore  not 
well  suited  for  the  proposed  method.  In  this  example,  however,  it  is  shown  how  stutter¬ 
ing  can  be  used  to  introduce  asynchronism  into  the  model  even  without  sacrificing  the 
synchronous  composition  model. 

•  The  aircraft  controller  example  illustrates  the  importance  of  the  efficiency  of  the  sym¬ 
bolic  algorithms  used  in  Verus.  As  discussed,  one  of  the  most  restrictive  factors  in  for¬ 
mal  verification  is  the  number  of  concurrent  processes  in  the  system,  due  to  the 
complexity  of  the  parallel  composition  algorithm.  In  this  example  we  have  shown  that 
systems  with  a  large  number  of  processes  can  be  efficiently  verified  by  Verus.  The  air¬ 
craft  controller  has  15  concurrent  processes,  but  quantitative  information  about  the  sys¬ 
tem  can  be  computed  in  seconds  using  a  486  computer. 

•  The  versatility  of  the  method  can  be  seen  in  the  robotics  and  medical  monitoring  exam¬ 
ples.  Because  of  their  design,  neither  example  can  be  directly  analyzed  by  the  rate 
monotonic  algorithms.  In  fact,  a  complex  extension  to  RMS  has  been  developed  to  han¬ 
dle  systems  such  as  the  robotics  controller  presented  [38].  The  quantitative  analysis 
performed  cannot  be  directly  done  using  standard  model  checking.  In  Verus,  however, 
both  systems  have  been  implemented  and  verified  in  a  straightforward  way.  This  shows 
how  Verus  can  easily  acconunodate  several  different  types  of  systems  and  properties. 

Moreover,  in  both  cases  the  analysis  performed  has  uncovered  inefficiencies  in  the 
design  and  suggested  optimizations.  Results  such  as  these  can  be  very  difficult  to  obtain 
using  other  tools.  After  modifying  the  design,  the  same  algorithms  have  been  used  to 
show  that  the  performance  of  the  system  has  improved.  These  examples  show  the  ver¬ 
satility  of  the  specification  language,  and  the  usefulness  of  the  results  produced  by  the 
verification  algorithms. 

•  The  PCI  local  bus  analysis  has  shown  that  not  only  real-time  systems  can  benefit  from 
the  new  method.  This  example  shows  how  timing  properties  of  non  real-time  systems 
can  be  analyzed,  and  how  those  results  can  be  used  to  help  understand  the  behavior  of 
systems  that  are  not  usually  associated  with  real-time. 
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Another  important  issue  has  been  discussed  in  the  analysis  of  the  PCI  bus.  Even  though 
limited  to  finite-state  systems,  Veras  can  produce  results  that  can  be  extrapolated  to 
larger  classes  of  systems.  In  this  example  restrictions  to  the  model  have  been  imple¬ 
mented  to  ensure  that  the  model  is  finite.  Later  the  results  generated  by  the  analysis 
have  been  extrapolated  to  different  configurations  of  the  PCI  that  are  not  limited  by 
those  restrictions.  This  shows  that  the  results  produced  by  the  algorithms  can  be  even 
more  general  and  useful  than  a  superficial  verification  might  lead  to  believe.  Sometimes 
a  careful  analysis  can  produce  information  that  might  have  seen  impossible  to  obtain 
due  to  the  characteristics  of  the  method,  as  has  been  the  case  in  this  example. 

•  The  distributed  real-time  system  analyzed  shows  a  combination  of  all  these  features 
into  an  analysis  that  would  be  very  difficult  to  perform  using  other  tools.  It  is  a  large 
complex  system  that  exceeds  the  complexity  of  systems  that  can  be  verified  using  con¬ 
tinuous  time  tools.  It  cannot  be  analyzed  directly  by  RMS,  because  RMS  does  not 
allow  a  complete  analysis  of  distributed  systems.  Moreover  the  quantitative  informa¬ 
tion  produced  would  be  very  difficult  if  not  impossible  to  obtain  using  techniques  such 
as  model  checking. 

In  Veras,  however,  we  have  been  able  to  model  the  system  naturally.  The  quantitative 
algorithms  have  been  applied  directly  to  the  model.  In  this  case  they  also  uncovered 
inefficiencies  and  suggested  optimizations  to  the  design.  Finally,  the  efficiency  of  the 
algorithms  allowed  results  to  be  produced  in  minutes  in  all  cases. 

These  examples  show  that  Veras  is  an  efficient  and  useful  tool  for  analyzing  real-time  sys¬ 
tems.  It  can  perform  analyses  that  are  impossible  or  extremely  difficult  to  do  using  previ¬ 
ous  methods.  The  technique  can  be  efficiently  applied  to  complex  real-time  and  non  real¬ 
time  systems  and  can  assist  in  determining  their  correctness  and  in  understanding  their 
behavior.  It  can  ultimately  contribute  to  the  implementation  of  more  efficient  and  reliable 
systems. 
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This  work  can  be  extended  in  many  directions.  For  example,  the  examples  discussed  pre¬ 
viously  show  that  many  different  types  of  analyses  can  be  performed.  The  verification  of 
more  examples  is  the  key  to  developing  new  ways  to  produce  and  analyze  information 
about  the  behavior  of  real-time  and  non  real-time  systems.  Particularly,  analyzing  systems 
in  different  areas  might  prove  useful  in  finding  new  ways  to  look  at  the  information  pro¬ 
duced.  Examples  of  areas  in  which  Vems  may  be  useful  are  flexible  manufacturing,  other 
types  of  industrial  controllers,  circuit  design  and  software  systems. 

An  important  extension  of  the  method  is  the  implementation  of  non-unit  transitions  in  the 
model.  Allowing  transitions  that  take  longer  than  one  time  unit  to  occur  can  help  increase 
the  efficiency  of  verification.  Less  states  in  the  model  are  generated  because  long  transi¬ 
tions  are  not  expanded  into  a  sequence  of  unit  transitions.  A  model  that  allows  transitions 
to  take  time  t  to  occur,  where  t  is  within  a  defined  time  range  has  been  developed  [12]. 
Research  is  needed,  however,  to  implement  an  efficient  parallel  composition  algorithm  for 
this  model. 

An  important  aspect  of  a  model  with  non-unit  transitions  is  the  fact  that  with  each  transi¬ 
tion  is  associated  an  entity,  in  this  case  a  time  range.  But  other  models  can  be  derived  from 
this  one  by  associating  transitions  with  other  entities.  One  useful  example  is  associating 
probabilities  with  transitions.  This  would  allow  the  computation  of  the  probability  of 
reaching  a  certain  state,  or  the  probability  of  reaching  a  steady-state.  A  probabilistic  model 
checker  has  many  important  applications,  but  much  research  is  still  needed  in  this  area. 

Another  potentially  important  extension  to  Verus  comes  from  noticing  that  two  different 
types  of  variables  exist  in  the  model.  Variables  that  model  the  control  or  data  in  the  sys¬ 
tem,  and  variables  that  model  time.  The  behavior  of  these  two  sets  of  variables  can  be  very 
different.  Time  variables  are  manipulated  in  a  restricted  way,  usually  by  resetting  or  incre¬ 
menting  their  value.  There  may  be  more  efficient  representations  for  those  variables  that 
optimize  the  representation  of  these  operations.  One  promising  candidate  representation  is 
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BMDs  [7].  BMDs  are  very  efficient  for  representing  arithmetic  operations,  and  can  per¬ 
haps  increase  the  efficiency  of  the  verification  on  Veras. 

Several  other  extensions  can  also  be  of  benefit,  such  as  extensions  to  the  Veras  language, 
or  the  exploration  of  synwnetry  in  the  models.  We  believe  that  this  work  can  be  only  the 
beginning  of  a  new  research  area  on  formal  verification  of  real-time  systems  using  quanti¬ 
tative  algorithms.  We  hope  to  be  able  to  continue  this  work  and  explore  some  of  these 
research  directions,  generating  in  the  end  an  even  more  efficient  and  useful  tool. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


197 


Conclusions 


198 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


Chapters  References 


[1]  R.  Alur,  C.  Courcourbetis,  and  D.  Dill.  Model-checking  for  real-time  systems.  In  Pro¬ 
ceedings  of  the  5^*  Symposium  on  Logics  in  Computer  Science,  pp.  414-425,  1990. 

[2]  R.  Alur  and  D.  Dill.  Automata  for  modeling  real-time  systems.  In  Lecture  Notes  in 
Computer  Science,  if^lCALP.  Springer-Verlag,  1990. 

[3]  R.  Alur  and  T.  Henzinger.  Logics  and  models  of  real-time:  a  survey.  In:  Lecture  Notes 
in  Computer  Science,  Real  Time:  Theory  in  Practice.  Springer-Verlag,  1992. 

[4]  ANSI  Std.  FDDI  Token  Ring  Media  Access  Control,  s3t95/83-16  edition,  1986. 

[5]  G.  Berry  and  G.  Gonthier.  The  ESTEREL  synchronous  programming  language: 
design,  semantics,  implementation.  In:  Science  of  Computer  Programming,  vol.  19, 1992. 

[6]  R.  E.  Bryant.  Graph-based  algorithms  for  boolean  function  manipulation.  IEEE  Trans¬ 
actions  on  Computers,  C-35(8),  1986. 

[7]  R.  E.  Bryant  and  Y.  A.  Chen.  Verification  of  arithmetic  functions  with  binary  moment 
diagrams.  Technical  Report  CMU-CS-94-160,  Carnegie  Mellon  University,  1994. 

[8]  J.  R.  Burch,  E.  M,  Clarke,  and  D.  E.  Long.  Symbolic  model  checking  with  partitioned 
transition  relations.  In  VLSI  91,  Edinburgh,  Scotland,  1990. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


199 


References 

[9]  J.  R.  Burch,  E.  M.  Clarke,  K.  L.  McMillan  and  D.  L.  Dill.  Sequential  circuit  verifica¬ 
tion  using  symbolic  model  checking.  In  27th  ACM/IEEE  Design  Automation  Conference,, 
June  1990. 

[10]  J.  R.  Burch,  E.  M.  Clarke,  K.  L.  McMillan,  D.  L.  Dill,  and  J.  Hwang.  Symbolic  model 
checking:  10^®  states  and  beyond.  In  Proceedings  of  the  5^^  Symposium  on  Logics  in  Com¬ 
puter  Science,  1990. 

[11]  S.  V.  Campos.  The  priority  inversion  problem  and  real-time  symbolic  model  check¬ 
ing.  Technical  Report  CMU-CS-93-125,  Carnegie  Mellon  University,  1993. 

[12]  S.  V.  Campos  and  E.  M.  Clarke.  Real-time  symbolic  model  checking  for  discrete  time 
models.  In  First  AMAST International  Workshop  in  Real-Time  Systems,  1993. 

[13]  S.  V.  Campos,  E.  M.  Clarke,  W.  Marrero,  M.  Minea,  and  H.  Hiraishi.  Computing 
quantitative  characteristics  of  finite-state  real-time  systems.  In  IEEE  Real-Time  Systems 
Symposium,  1994. 

[14]  S.  V.  Campos,  E.  M.  Clarke,  W.  Marrero  and  M.  Minea.  Timing  analysis  of  industrial 
real-time  systems.  In:  Workshop  on  Industrial-strength  Formal  specification  Techniques, 
1995. 

[15]  S.  V.  Campos,  E.  M.  Clarke,  W.  Marrero  and  M.  Minea.  Verifying  the  performance  of 
the  PCI  local  bus  using  symbolic  techniques.  In:  ICCD,  1995. 

[16]  S.  V.  Campos,  E.  M.  Clarke,  W.  Marrero  and  M.  Minea.  Verus:  a  tool  for  quantitative 
analysis  of  finite-state  real-time  systems.  In:  Workshop  on  Languages,  Compilers  and 
Tools  for  Real-Time  Systems,  1995. 

[17]  Z.  Chaochen,  C.  Hoare  and  A.  Ravn.  A  calculus  of  durations.  Information  Processing 
Letters,  40,  5, 1991. 

[18]  D.  Clarke,  H.  Ben-Abdallah,  I.  Lee,  H.  Xie  and  O.  Sokolsky.  XVERSA:  an  integrated 
graphical  and  textual  toolset  for  the  specification  and  analysis  of  resource-bound  real-time 
systems.  In:  Proceedings  of  the  8th  Conference  on  Computer-Aided  Verification,  Lecture 
Notes  in  Computer  Science  1102.  Springer- Verlag,  1996. 

A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


200 


[19]  E.  M.  Clarke  and  E.  A.  Emerson.  Synthesis  of  synchronization  skeletons  for  branch¬ 
ing  time  temporal  logic.  In  Logic  of  Programs:  Workshop,  Yorktown  Heights,  NY,  May 
7957.  LNCS  131,  Springer- Verlag,  1981. 

[20]  E.  M.  Clarke,  E.  A.  Emerson,  and  A.  P.  Sistla.  Automatic  verification  of  finite-state 
concurrent  systems  using  temporal  logic  specifications.  ACM  TOPLAS,  8(2):244-263, 
1986. 

[21]  E.  Clarke,  O.  Grumberg,  K.  Hamaguchi.  Another  look  at  LTL  model  checking.  Tech¬ 
nical  Report  CMU-CS-94-114,  Carnegie  Mellon  University,  School  of  Computer  Science, 
1994. 

[22]  E.  Clarke,  O.  Grumberg,  and  H.  Hamaguchi.  Another  look  at  LTL  model  checking. 
In:  Proceedings  of  the  Sixth  Conference  on  Computer-Aided  Verification,  Lecture  Notes  in 
Computer  Science  818,  pages  415-427.  Springer- Verlag,  1994. 

[23]  E.  M.  Clarke,  O.  Grumberg,  H.  Hiraishi,  S.  Jha,  D.  E.  Long,  K.  L.  McMillan,  and  L. 
A.  Ness.  Verification  of  the  Futurebus'*’  cache  coherence  protocol.  In  Proceedings  of  the 

CHDL,  1993. 

[24]  E.  Clarke,  O.  Grumberg,  and  D.  Long.  Model  checking  and  abstraction.  In  Proceed¬ 
ings  of  the  19^^  ACM  Symposium  on  Principles  of  Programming  Languages,  1992. 

[25]  E.  Clarke,  O.  Grumberg,  and  D.  Long.  Verification  tools  for  finite-state  concurrent 
systems.  In:  REX’93  School/Workshop:  A  Decade  of  Concurrency,  Nordwijkerhout,  The 
Netherlands,  Junel993. 

[26]  O.  Coudert,  C.  Berthet,  and  J.  Madre.  Verification  of  synchronous  sequential 
machines  based  on  symbolic  execution.  In  Automatic  Verification  Methods  for  Finite  State 
Systems,  International  Workshop,  Grenoble,France,  Lecture  Notes  in  Computer  Science, 
vol.  407,  Springer- Verlag,  June,  1989. 

[27]  P.  Clements,  C.  Heitmeyer,  G.  Labaw,  and  A.  Rose.  MT:  a  toolset  for  specifying  and 
analyzing  real-time  systems.  In  IEEE  Real-Time  Systems  Symposium,  1993. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


201 


References 


[28]  R.  Cleaveland,  R  Lewis,  S.  Smolka  and  O.  Sokolsky.  The  concurrency  factory:  a 
development  environment  for  concurrent  systems.  In:  Proceedings  of  the  8th  Conference 
on  Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science  1102.  Springer- Ver- 
lag,  1996. 

[29]  R.  Cleaveland  and  S.  Sims.  The  NCSU  concurrency  workbench.  In:  Proceedings  of 
the  8th  Conference  on  Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science 
1102.  Springer- Verlag,  1996. 

[30]  D.  Dill.  The  Murtp  verification  system.  In:  Proceedings  of  the  8th  Conference  on 
Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science  1102.  Springer- Verlag, 
1996. 

[31]  P.  Drongowski.  Software  architecture  in  real-time  systems.  In  IEEE  Workshop  on 
Real-Time  Applications,  1993. 

[32]  E.A.  Emerson  and  Chin  Laung  Lei.  Modalities  for  Model  Checking:  Branching  Time 
Strikes  Back.  In  Twelfth  Symposium  on  Principles  of  Programming  Languages,  January, 
1985. 

[33]  E.  A.  Emerson,  A.  K.  Mok,  A.  P.  Sistla,  and  J.  Srinivasan.  Quantitative  temporal  rea¬ 
soning.  In  Lecture  Notes  in  Computer  Science,  Computer-Aided  Verification.  Springer- 
Verlag,  1990. 

[34]  J.  Fernandez,  H.  Garavel,  A.  Kerbrat,  L.  Mounier,  R.  Mateescu  and  M.  Sighireanu. 
CADP:  a  protocol  validation  and  verification  toolbox.  In:  Proceedings  of  the  8th  Confer¬ 
ence  on  Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science  1102.  Springer- 
Verlag,  1996. 

[35]  A.  N.  Fredette  and  R.  Cleaveland.  RTSL:  a  language  for  real-time  schedulability 
analysis.  In  IEEE  Real-Time  Systems  Symposium,  1993. 

[36]  R.  Gerber  and  I.  Lee.  A  proof  system  for  communicating  shared  resources.  In  IEEE 
Real-Time  Systems  Symposium,  1990. 


202 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


[37]  P.  Le  Guemic,  M.  Le  Borgne,  T.  Gautier  and  C.  Le  Maire.  Programming  real  time 
applications  with  Signal.  Technical  Report  1446,  INRIA,  Rennes,  1991. 

[38]  M.  G.  Harbour,  M.  H.  Klein,  and  J.  P.  Lehoczky.  Timing  analysis  for  fixed-priority 
scheduling  of  hard  real-time  systems.  IEEE  Transactions  on  Software  Engineering,  20(1), 
1994. 

[39]  R.  Hardin,  Z.  Har’El  and  R.  Kurshan.  COSPAN.  In:  Proceedings  of  the  8th  Confer¬ 
ence  on  Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science  1102.  Springer- 
Verlag,  1996. 

[40]  C.  Heitmeyer  and  N.  Lynch.  The  generalized  railroad  crossing:  a  case  study  in  formal 
verification  of  real-time  systems.  IEEE  Real-Time  Systems  Symposium,  1994. 

[41]  T.  Henzinger,  X.  Nicollin,  J.  Sifakis,  and  S.  Yovine.  Symbolic  model  checking  for 
real-time  systems.  In  Proceedings  of  the  7^^  Symposium  on  Logic  in  Computer  Science, 
1992. 

[42]  T.  Henzinger,  P.  Ho,  and  H.  Wong-Toi.  HyTech:  the  next  generation.  In  IEEE  Real- 
Time  Systems  Symposium,  1995. 

[43]  G.  Holzmann  and  D.  Peled.  The  state  of  Spin.  In:  Proceedings  of  the  8th  Conference 
on  Computer-Aided  Verification,  Lecture  Notes  in  Computer  Science  1102.  Springer- Ver- 
lag,  1996. 

[44]  TFHF.  Standard  Board  and  American  National  Standards  Institute.  Standard  Back¬ 
plane  Bus  Specification  for  Multiprocessor  Architectures:  Futurebus+,  ansi/ieee  std  896.1 
edition,  1990. 

[45]  Intel  Corporation.  82378  System  I/O  (SIO)  —  PCI  Local  Bus,  1993. 

[46]  Intel  Corporation.  PCI  Local  Bus  Specification,  1993. 

[47]  F.  Jahanian  and  D.  Stuart.  A  method  for  verifying  properties  of  modechart  specifica¬ 
tions.  In:  IEEE  Real-Time  Systems  Symposium,  1988. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


203 


References 


[48]  M.  Joseph  and  P.  Pandya,  Finding  response  times  in  a  real-time  system.  In:  The  Com¬ 
puter  Journal,  29(5),  390-394, 1986. 

[49]  J.  P.  Lehoczky.  Real-time  resource  management  techniques.  Encyclopedia  of  Soft¬ 
ware  Engineering.  John-Wiley  &  Sons,  1994. 

[50]  J.  P.  Lehoczky.  Fixed  priority  scheduling  of  periodic  task  sets  with  arbitrary  dead¬ 
lines.  In  IEEE  Real-Time  Systems  Symposium,  1990. 

[51]  J.  P.  Lehoczky  and  L.  Sha.  Performance  of  real-time  bus  scheduling  algorithms.  ACM 
Performance  Evaluation  Review,  14,  1986. 

[52]  J.  P.  Lehoczky,  L.  Sha  and  Y.  Ding.  The  rate  monotonic  scheduling  algorithm:  exact 
characterization  and  average  case  behavior.  In  IEEE  Real-Time  Systems  Symposium,  1989. 

[53]  J.  P.  Lehoczky,  L.  Sha,  J.  K.  Strosnider,  and  H.  Tokuda.  Fixed  priority  scheduling  the¬ 
ory  for  hard  real-time  systems.  In  Foundations  of  Real-Time  Computing  -  Scheduling  and 
Resource  Management.  Kluwer  Academic  Publishers,  1991. 

[54]  J.  Leung  and  J.  Whitehead.  On  the  complexity  of  fixed-priority  scheduling  of  peri¬ 
odic,  real-time  tasks.  Performance  Evaluation,  2, 1982. 

[55]  H.  Lewis.  A  logic  of  concrete  time  intervals.  In  Proceedings  of  the  5^^  Symposium  on 
Logic  in  Computer  Science,  \990. 

[56]  O.  Lichtenstein  and  A.  Pnueli.  Checking  that  finite  state  concurrent  programs  satisfy 
their  linear  specification.  In:  Proceedings  of  the  twelfth  Conference  on  Principle  of  Pro¬ 
gramming  languages,  January  1985. 

[57]  O.  Lichtenstein,  A.  Pnueli  and  L.  Zuck.  The  Glory  of  the  Past.  In  Proc.  Conf  Logics 
of  Programs,  Lecture  Notes  in  Computer  Science  193,  Springer- Verlag,  1985. 

[58]  B.  Lin  and  A.  R.  Newton.  Efficient  symbolic  manipulation  of  equivalence  relations 
and  classes.  In:  Proc.  of  the  Int.  Workshop  on  Formal  Methods  in  VLSI  Design,  1991. 


204 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


[59]  C.  L.  Liu  and  J.  W.  Layland.  Scheduling  algorithms  for  multiprogramming  in  a  hard 
real-time  environment.  Journal  of  the  ACM,  20(1),  1973. 

[60]  C.  Locke,  D.  Vogel,  and  T.  Mesler.  Building  a  predictable  avionics  platform  in  Ada:  a 
case  study.  In  IEEE  Real-Time  Systems  Symposium,  1991. 

[61]  Z.  Manna  and  A.  Pnueli.  The  Anchored  Version  of  the  Temporal  Framework.  In  Lin¬ 
ear  Time.  Branching  Time  and  Partial  Order  in  Logics  and  Models  for  Concurrency,  Lec¬ 
ture  Notes  in  Computer  Science  354,  Springer- Verlag,  1989. 

[62]  K.  L.  McMillan.  Symbolic  model  checking  -  an  approach  to  the  state  explosion  prob¬ 
lem.  Ph.D.  thesis,  SCS,  Carnegie  Mellon  University,  1992. 

[63]  X.  Nicollin,  J.  Sifakis,  and  S.  Yovine.  From  ATP  to  timed  graphs  and  hybrid  systems. 
In  Lecture  Notes  in  Computer  Science,  Real-Time:  Theory  in  Practice.  Springer- Verlag, 
1992. 

[64]  D.  T.  Peng  and  K.  G.  Shin.  A  new  performance  measure  for  scheduling  independent 
real-time  tasks.  Technical  Report,  Real-Time  Computing  Laboratory,  University  of  Michi¬ 
gan,  1989. 

[65]  A.  Pnueli.  The  Temporal  Semantics  of  Concurrent  Programs.  In  Proceedings  of  the 
eighteenth  conference  on  Foundation  of  Computer  Science,  1977. 

[66]  R.  Rajkumar.  Task  synchronization  in  real-time  systems.  Ph.D.  thesis,  ECE,  Carnegie 
Mellon  University,  1989. 

[67]  Y.  Ramakrishna,  P.  Melliar-Smith,  L.  Moser,  L.  Dillon,  and  G.  Kutty.  Really  visual 
temporal  reasoning.  In  IEEE  Real-Time  Systems  Symposium,  1993. 

[68]  L.  Sha,  M.  H.  Klein,  and  J.  B.  Goodenough.  Rate  monotonic  analysis  for  real-time 
systems.  In  Foundations  of  Real-Time  Computing  -  Scheduling  and  Resource  Manage¬ 
ment.  Kluwer  Academic  Publishers,  1991. 

[69]  L.  Sha,  R.  Rajkumar  and  S.  Sathaye.  Generalized  rate-monotonic  scheduling  theory: 
a  framework  for  developing  real-time  systems.  In  Proceedings  of  the  IEEE,  Jan  1994. 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


205 


References 


[70]  B.  Sprunt.  Aperiodic  task  scheduling  for  real-time  systems.  Ph.  D.  dissertation, 
Department  of  Electrical  and  Computer  engineering,  Carnegie  Mellon  University,  1990. 

[71]  J.  K.  Strosnider.  Highly  responsive  real-time  token  rings.  Ph.  D.  dissertation.  Depart¬ 
ment  of  Electrical  and  Computer  engineering,  Carnegie  Mellon  University,  1988. 

[72]  G.  Thuau  and  D.  Pilaud.  Using  the  declarative  language  Lustre  for  circuit  verifica¬ 
tion.  In:  Workshops  in  Computing  —  Designing  Correct  Circuits,  Springer- Verlag,  1990. 

[73]  H.  Touati,  H.  Savoj,  B.  Lin,  R.  Brayton  and  A.  Sangiovanni-Vincentelli.  Implicit  state 
enumeration  of  finite  state  machines  using  BDDs.  In  IEEE  International  Conference  on 
Computer-Aided  Design,  1990. 

[74]  M.  Vardi  and  P.  Wolper.  An  Automata-Theoretic  Approach  to  Automatic  Program 
Verification.  In  Proceedings  of  the  First  Symposium  on  Logic  in  Computer  Science,  1986. 

[75]  F.  Wang.  Timing  behavior  analysis  for  real-time  systems.  In  Proceedings  of  the  Tenth 
Symposium  on  Logic  in  Coomputer  Science,  1995. 

[76]  G.  Winskel.  The  Formal  Semantics  of  Programming  Languages,  an  Introduction.  The 
MIT  Press,  1994,  pp.  135-139. 

[77]  J.  Yang,  A.  K.  Mok,  and  F.  Wang.  Symbolic  model  checking  for  event-driven  real¬ 
time  systems.  In  IEEE  Real-Time  Systems  Symposium,  1993. 

[78]  X.  Zhao.  Personal  communication. 


206 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


Index 


A 

air  traffic  control  system  142 
aircraft  controller  27, 157 
analysis  162 
model  160 
response  times  164 
schedulability  162 
algorithms 

interval  model  checking  120 
lazy  composition  136 
maximum  count  24, 101 
maximum  delay  24,92 
minimum  count  24, 97 
minimum  delay  24,  90 
optimized  maximum  count  106 
optimized  minimum  count  102 
parallel  composition  136 
selective  quantitative  analysis  over  intervals  117 
selective  quantitative  analysis  over  paths  1 1 6 
synchronous  composition  in  Verus  136 
assignment  statement  75 
asynchronous  composition  136 

B 

BDD  36 

binary  decision  diagrams  36 
bounded  priority  inversion  143 
bounded  until  88 


continuous  time  17 
control  flow  in  Verus  67 
core  language  semantics  71 
counterexamples  32 
CTL  33 

D 

data  types  in  Verus  52 
deadline  statement  57, 79 
discrete  time  17 

distributed  real-time  system  186 
analysis  189 
dynamic  scheduling  43 

E 

exception  handling  58,  80 
expressions,  semantics  73 
extension  language  semantics  78 
external  variables  60,73,75 

F 

FDDI  network  186 
fixpoint  77 

fixpoint  characterization  39 
Futurebus  187 

G 

graphs  in  Verus  65 


C 

C  language  21,51 
computation  tree  logic  33 
concurrency  semantics  82 
constrain  operator  138 


I 

if  statement  77 
initial  state  set  70 
integer  size  61 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


207 


Index 


interleaving  composition  136 
internal  variables  60,73,75 
interval  model  checking  24, 109, 120 

L 

languages 
C  21,51 
Esterel  21 
Lustre  21 
Modechart  21 
Signal  21 
SMV  21 
Veras  21,51 

lazy  composition  20, 136 
linear-time  temporal  logic  25, 110,  111 
LTL  25, 110,  111 
LTL tableau  111 

M 

maximum  count  algorithm  24, 101 
maximum  delay  algorithm  24, 92 
medical  monitoring  system  170 
analysis  171 
optimization  174 
minimum  count  algorithm  24, 97 
minimum  delay  algorithm  24,90 
model  checking  31 
model  checking  algorithm  40 

N 

nondeterminism  in  Veras  54 
nonpreemptive  vs  preemptive  schedulers  163 

O 

optimized  maximum  count  algorithm  106 
optimized  minimum  count  algorithm  102 

P 

parallel  composition 
in  model  checking  39 
in  Veras  56 

parallel  composition  algorithm  136 
partitioned  transition  relations  137 
PCI  local  bus  175 
analysis  178 
arbitration  177 
transaction  abort  183 
transactions  176 
periodic  statement  56,  79 
preemptive  vs  non  preemptive  schedulers  163 
prioritized  composition  83 
priority  inheritance  144 
priority  inversion  141 
priority  statement  60 
process  instantiation  in  Veras  56, 64 


producer/consumer  example  52 

Q 

quantitative  algorithms  24 
quantitative  analysis  89 

R 

rate  monotonic  scheduling  theory  16 
reachability  analysis  17 
real-time  CTL  23, 87 
region  graph  17 
RMS 

aperiodic  tasks  47 
exact  schedulability  analysis  45 
task  synchronization  46 
robotics  controller  27, 165 
analysis  167 
RTCTL  23,  87 

S 

schedulers  in  Veras  84 
scheduling 
dynamic  43 
static  44 

select  statement  54 

selective  quantitative  analysis  24, 109, 189 
selective  quantitative  analysis  over  intervals  117 
selective  quantitative  analysis  over  paths  116 
semantics 
concurrency  82 
core  language  71 
expressions  73 
extension  language  78 
statements  71,  75 
semantics  of  Veras  65 
statements 
assignment  75 
deadline  57,79 
handler  58,  80 
if  77 

periodic  56,79 
priority  60 
select  54 
semantics  71,75 
wait  54, 67,  75 
while  77 

state-transition  graphs  in  Veras  20,  65 
static  scheduling  44 
stuttering  56,  83,  152 
symbolic  model  checking  35 
synchronous  composition  82, 136 
synchronous  composition  in  Veras  136 

T 

tableau  for  LTL  111 


208 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


temporal  logic  31,33 

temporal  logic  model  checking  15, 3 1 

transition  relation,  representation  66 

U 

^  unbounded  priority  inversion  143 

V 

^  Verus 

and  model  checking  41 
and  RMS  48 
characteristics  18 
contributions  and  comparisons  27 
datatypes  52 

internal  and  external  variables  60,  73, 75 

nondeterminism  54 

parallel  composition  56 

process  instantiation  56,  64 

schedulers  84 

semantics  65 

state-transition  graphs  65 

synchronous  composition  algorithm  136 

syntax  60 

syntax  of  extensions  63 
syntax  of  the  core  language  61 
Verus  language  21,51 

W 

wait  counters  69 
wait  graphs  67 
wait  statement  54, 67, 75 
while  statement  77 


9 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


209 


Index 


210 


A  Quantitative  Approach  to  the  Formal  Verification  of  Real-Time  Systems 


